[rfc-i] For v3: Better identification for multi-document sets

Julian Reschke julian.reschke at gmx.de
Sat Dec 28 13:59:23 PST 2013


On 2013-12-28 22:28, Jim Schaad wrote:
>
>
>> -----Original Message-----
>> From: rfc-interest-bounces at rfc-editor.org
> [mailto:rfc-interest-bounces at rfc-
>> editor.org] On Behalf Of Julian Reschke
>> Sent: Friday, December 27, 2013 10:56 AM
>> To: Paul Hoffman; RFC Interest
>> Subject: Re: [rfc-i] For v3: Better identification for multi-document sets
>>
>> On 2013-12-24 04:42, Paul Hoffman wrote:
>>> There are many multi-RFC BCPs and multi-document standards from
>> another SDOs. Maybe we should add and element or attribute to make
>> reference to these normalized.
>>>
>>> --Paul Hoffman
>>
>> +1
>>
>> See proposal from John Klensin in
>> <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/106> from which we
>> should start:
>>
>>> It would allow the right thing to happen if, e.g.,
>>>   (i) <reference> were modified to allow an "aggregate='yes'"
>>> attribute so that, with that attribute turned on,
>>>    <reference anchor="BCP0101">
>>>       &rfc3777;
>>>       &rfc5633;
>>>       &rfc5680;
>>>       &rfc6859;
>>>    </reference>
>>>
>>> would suppress the individual anchors on output but otherwise do the
>>> right thing.  And
>>
>> The tricky part is whether the container itself should allow certain child
>> elements such as <title>, and also what to do with the seriesInfo elements
> in
>> nested <references> that repeat the container information.
>
> Another issue that needs to be considered is the question of recursion.
> Should I be able to do
>
> <reference anchor="Keywords">
>    <reference anchor="BCPXXXX">
>      <reference anchor="RFC2119">
>
> Jim

It's an interesting thought; do we have a use case?

DTD-wise the right answer might be to pick a different name for the 
reference container.

Best regards, Julian



More information about the rfc-interest mailing list