[rfc-i] New Version Notification for draft-hoffman-xml2rfc-18.txt
henrik at levkowetz.com
Wed Jun 3 02:52:11 PDT 2015
On 2015-06-02 20:31, Paul Hoffman wrote:
>> > Ack, but the specification now seems introduces the limitation that the <eref>
>> > may not point to something which is also in the references section. From
>> > your reaction, I understand that this may not have been your intention, though;
>> > it is however what I got from the current text.
> I can better explain that, definitely.
>> > Ok, in that case I'd suggest that the language in 2.24 be changed. I'd also
>> > prefer to stick with the <xref>, as it's known, and removing functionality
>> > from it would break backwards compatibility, no?
> <xref> in v2 doesn't have the functionality that Julian is talking
> about, which is "if a Reference is to a specific URL (such as an
> RFC), how do can the author refer directly to part of that reference
> (such as Section 2.3 of that RFC)".
> In earlier drafts of the v3, we
> put these extensions in <xref> but didn't explain fully what it
> meant. In doing that fuller explanation, I realized that it was a
> tangle of "it means X unless Y is present or Z is not present". It
> seemed clearer to me to move that new functionality to a new element
> and leave <xref> meaning what it did in v2. Julian disagrees, saying
> that he prefers it to be in <xref>. I have asked him to show exactly
> how that would work.
To me, the most important point is to make it easy for the user to
grasp and use the markup; whether that makes the processor code
simple or complex is secondary (although not negigible). From that
viewpoint, I think that continuing to use <xref> is probably the best
-- having to shift back and forth between <xref> and <relref> as a
function of wanting to specify a fragment identifier or not seems
cumbersome and not (to me) intuitive.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the rfc-interest