Re: [xml2rfc-dev] v3 <seriesInfo> vs IMPNOTES vs canonical XML

[Heather Flanagan <[e-mail]>]

> On Dec 19, 2019, at 3:38 AM, Julian Reschke <[e-mail]> wrote:
> 
> On 31.10.2019 14:03, Julian Reschke wrote:
>> On 29.10.2019 19:30, Heather Flanagan wrote:
>>> ...
>>> 
>>> Right now, I’m in the middle of trying to figure out how to capture
>>> the reality of <seriesInfo> and make appropriate changes. After that,
>>> it will be <sourcecode> and then (if my brain hasn’t melted)
>>> “keepWithNext”.
>>> 
>>> -Heather
>>> ...
>> 
>> That is indeed both important and complex. I'll try to give feedback
>> soonish.
>> 
>> Best regards, Julian
> 
> So this is currently captured in
> <https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-3.1.21>,
> quoting the summary:
> 
>> 3.1.21.5.  Summary
>> 
>>   The number of issues introduced with the move of the <seriesInfo>
>>   element and its re-purposing in order to fill functionality in the
>>   front of a document is wholly disproportionate with any added
>>   functionality.  The specification [RFC7991] does not provide any
>>   rationale for the changes, and there seems to be no major benefits to
>>   the new schema.
>> 
>>   Proposal:  Do a rewrite of this that does not add new details to the
>>      already complex <seriesInfo> semantics, compared to the v2
>>      vocabulary, and does not make non-IETF reference files obsolete,
>>      but actually simplifies the model and use.
>> 
>>      Limit the <seriesInfo> element to what is actually needed for use
>>      within <reference/>, and do not add new functionality related to
>>      the document <front>.  Deprecate any functionality not related to
>>      usage within <reference/>.
>> 
>>      The easiest approach would be to simply revert to the v2 semantics
>>      and placement of <seriesInfo> elements, with documentation of
>>      that.
>> 
>>   Implementation:  The current implementation does not strip or
>>      disregard the attributes on <rfc>; apart from that the schema is
>>      not reverted to v2 in the current implementation, but see also
>>      Section 3.1.17, Section 3.1.19 and Section 3.2.2.
> 
> I fully agree with this.
> 
> The bad news is that with the proposed change, the so-called "canonical
> XML" that has been published in the last three months would become invalid.
> 
> I believe we need to compile a list of issues that fall into the same
> category (the <br> discussion comes to mind as well), and then (1) fix
> these issues and then (2) both mechanically fix the published XML and
> re-generate the output formats (which in theory should not change at all
> if we do things right).

While that is technically possible (to mechanically update source files), it is against policy. What you’re suggesting is in effect changing the canonical source file, and we’ve said that’s not something we’re going to do.

I expect future vocabulary changes may well make older XML invalid (in the same way that v2 XML is not v3 valid). We’re not going to go back and change the files to match whatever the new reality is; I don’t see this as significantly different a situation. John and the rest of the community may decide different in the future, of course, but I never intended changing source files for any reason.

-Heather