unexpected "type" attribute on <list> element
reschke opened this issue · 12 comments
When converting https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md with version 1.7.11, I get:
<t><list style="numbers" type="1">
<t>Using the grammar below, divide the cookie-date into date-tokens. <vspace blankLines='1'/>
This did not happen with 1.7.8.
Of course, I could suppress the default value, which I'll probably do.
But what you see is a feature, not a bug, and type= is a settable IAL attribute for a list in kramdown-rfc's source language.
kramdown-rfc generates the input language of the v2v3 component of xml2rfc, and that allows a type= attribute here.
Doing an xml2rfc --v2v3 first enables the use of tools that don't.
What I don't get is that the source file doesn't seem to contain anything that triggers it.
The file being generated fails to translate with xml2rfc, so I'm not sure how this is supposed to work.
I'm also not aware of a type attribute on the list element. Where is this defined?
So, if I understand correctly, xml2rfc's "--v2v3" conversion converts a list attribute that does not even exist in the v2 grammar?
Yes. The "v2" vocabulary of xml2rfc includes the "v3" vocabulary.
If this is a problem, we could of course fix this specifically for <list; I'll not try to second-guess the "v3" that xml2rfc implements, though.
Wait. There is no xml2rfc grammar that defines list/@type. This seems to be a side-effect of how xml2rfc does the conversion. Or am I missing something here?
Wait. There is no xml2rfc grammar that defines list/@type. This seems to be a side-effect of how xml2rfc does the conversion.
Exactly.
Essentially, the v2v3 code is part of kramdown-rfc's RFCXML generation.
Ok.
I have added a workaround to my tool chain.
Of course, the right fix for this would be to generate V3 XML in the first place...
Ok.
I have added a workaround to my tool chain.
Of course, the right fix for this would be to generate V3 XML in the first place...
What is V3 XML? I'd say, only xml2rfc knows, so I let it do the work.
So instead of producing the relatively well specified v3 syntax, you prefer to generate something completely undocumented?
I believe the most important objective here is stability. xml2rfc is stable. We are wrangling with documenting v3 in rswg right now. rswg has abdicated from the authoring parts of RFCXML, though.
It's more complicated...