[Standards] Proposed DTD fixes
jsf at edwinm.ik.nu
Wed Aug 31 06:47:37 UTC 2016
On 30/08/16 20:23, Kevin Smith wrote:
> On 30 Aug 2016, at 18:47, Steve Kille <steve.kille at isode.com> wrote:
>>> Our DTD seems to reject the vast majority of our XEPs. In part, this is
>>> because there are true mistakes in XEPs – e.g., <i/> where the author actually
>>> should've used <em/> – which aren't converted to the expected HTML, and
>>> in part because the DTD is too strict. I have just submitted a proposed DTD
>>> change at https://github.com/xsf/xeps/pull/242 that will address (most of)
>>> the latter.
>> This seems very helpful.
> Yes, I merged it immediately
>> I am using an XML editor that enforces compliance to DTD (oXygen), and I think it would be generally desirable to have all XEPs follow the DTD.
>> Perhaps Travis should do a check?
> We can, if we take care to only validate the modified XEPs, not the whole suite, but there’s a significant danger that we’ll discourage patches for any XEP that doesn’t match the DTD, as folks wouldn’t be able to submit changes without fixing up the other issues, be they either in the XEP or the DTD, so unless someone wants to resolve the remaining issues (ideally for the XSD as well, but at least in the DTD) it’s not clear that it’s the best thing (it’s not clear that it’s not, either).
I will at one point look at the XSDs. But for starters, none of our
XEPs declare the xmlns on their roots, that's why not even one XEP will
validate against it. Once that hurdle is passed, I'm sure many other
problems will surface, such as the obviously incorrect data types of
//header/revision/initials and //header/number.
> I wonder if we could run pre-patch vs post-patch tests for the modified XEP, and only fail if it passed before and now fails, so that modifications to a XEP that doesn’t pass the DTD at the moment get a free pass. Not sure I’d much like to be the one to script that, though.
The free pass idea sounds good to me.
More information about the Standards