[rfc-i] reference extensions
julian.reschke at gmx.de
Mon Feb 17 10:05:53 PST 2014
On 2014-02-17 17:50, Paul Hoffman wrote:
> On Feb 17, 2014, at 8:27 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
>>>>> The two popular methods now for references to RFCs are entering the
>>>>> whole reference by hand (hopefully getting all the fiddly bits of
>>>>> <front> and <seriesinfo> correct), or using XML entities that call
>>>>> out the xml.resource.org. Both work, but both have their faults.
>>>>> The first requires good copying skills and sometimes causes difficult
>>>> What exactly do you mean by "good copying skills"? The ability to copy and paste from an XML document? Maybe that's something we can address by just creating easier-to-use libraries.
>>> We could do that. How would it possibly be easier than using the new attributes?
>> It's easier in that it doesn't require anything new; it also avoids hardwiring knowledge about reference libraries into the processor.
> Sorry, I meant easier for the hundreds/thousands of people writing Internet Drafts. Minimizing the work for the people writing the processor at the expense of the people writing drafts is the wrong optimization.
We'll keep disagreeing about this. It's not a question of minimizing
work for implementers, but to avoid complex things that will be hard to
>> If the series information was a child element instead of an attribute, it would be simple to express the constraint in the grammar (it might be possible with attributes in RNG, but then we'd have the first case of a grammar constraint that's not expressible in the DTD as well).
> ...which brings us back to the other thread about whether expression in the DTD is necessary.
>>> Having a canonical RFC have an inclusion from an external source seems like a very bad idea for stability. Instead, we should keep requiring that the canonical RFC be complete and unchanging.
>> Yes, the canonical document needs to be self-contained. Your proposal doesn't solve this, unless you assume that the new notation always identifies immutable information.
You do assume that? In which case you'll need to very clear about the
kind of references that you'll support. For instance, unversioned ID
references (such as those in
<http://xml.resource.org/public/rfc/bibxml3/>) will not work. (Note that
I personally would consider that a feature, but others may disagree).
>> That may be true for RFCs, but it's not true for many other things people want to reference, such as internet drafts.
> An Internet Draft with a particular complete filename is a stable reference. The RFC Editor would treat these the same way in v3 as they do now.
Best regards, Julian
More information about the rfc-interest