stpeter at mozilla.com
Wed Aug 4 11:09:12 PDT 2021
Hi Julian, apologies for the delayed reply.
On 7/20/21 2:03 AM, Julian Reschke wrote:
> Am 20.07.2021 um 02:06 schrieb Peter Saint-Andre:
>> There's been some confusion about the <seriesInfo> element:
>> - When <seriesInfo> is a child of <reference>, the 'stream' attribute
>> isn't used.
>> - When <seriesInfo> is a child of <front>, it's unclear how exactly to
>> handle the 'stream' attribute. For instance, since <seriesInfo> can
>> appear more than once (such as in the case of a BCP), there's potential
>> confusion if the values of the 'stream' attribute are inconsistent.
>> - The 'status' attribute hasn't been used at all.
>> Based on discussion in the RFC XML and style guide change management
>> team, here is a proposal:
>> 1. Remove 'stream' from <seriesInfo>
>> 2. Add a new <stream> element as a child of <front>
>> 3. Remove 'status' from <seriesInfo>
>> As far as I can see, this would make the use of <seriesInfo> consistent
>> whether it is a child of <front> or <reference>.
>> Feedback is welcome.
> As far as I can tell from a quick check of AUTH48 XML (attached), the
> only use of the stream attribute so far was inside the document's front,
> and it always replicates the value in /rfc/@submissionType. So what is
> it actually for?
You make a good point. As far as I can see we don't need two document
constructs (/rfc/@submissionType and /rfc/front/seriesInfo at stream) that
contain the same information, so IMHO we can retain only the former and
nix my proposal to create a new <stream/> element. I don't recall why
RFC 7991 included both.
> If the use case is to augment a *reference* with more data - why hasn't
> it be used for that? This really needs a proper design with clear use
> cases, and the solution optimally should not ne specific for IETF
> documents (hint: there's already <refcontent>).
Well, @stream hasn't been used in reference files, which is partly why I
think we can remove it from seriesInfo entirely.
More information about the rfc-interest