[rfc-i] New Version Notification for draft-hoffman-xml2rfc-18.txt
paul.hoffman at vpnc.org
Tue Jun 2 11:31:03 PDT 2015
On Jun 2, 2015, at 11:14 AM, Henrik Levkowetz <henrik at levkowetz.com> wrote:
> Hi Paul,
> On 2015-06-02 17:59, Paul Hoffman wrote:
>> On Jun 2, 2015, at 8:20 AM, Henrik Levkowetz <henrik at levkowetz.com> wrote:
>>> On 2015-05-26 23:27, Paul Hoffman wrote:
>>>> - A change in the design of relative references. In earlier drafts,
>>>> relative references were done as additional attributes in <xref>; in
>>>> the new draft, <xref> acts as it does in v2, and there is a new
>>>> <relref> element for relative references. This was done to make it
>>>> easier for authors to understand how the XML they create will be
>>>> processed. Please read <eref> and <relref> and <xref> for a complete
>>>> description, including examples of how the HTML for each might be
>>> I've read the sections on <eref>, <relref> and <xref>, and there are a
>>> few things that bothers me. Taking up one of them in this message:
>>> From -18:
>>> 2.24. <eref>
>>> A link to URI that is not in the References section. This is useful
>>> for embedding URIs in the body of a document.
>>> 2.44. <relref>
>>> A relative link to a reference from the References section.
>>> Formatters that have links (such as HTML and PDF) are likely to
>>> render <relref> elements as live external links to the specified part
>>> of the reference, creating the link target by combining the base URI
>>> from the <reference> element with the "relative" attribute from this
>>> element. The "target" attribute is required, and it must be the
>>> anchor of a <reference> element.
>>> This means that if I create a document where I use eref to link to an
>>> external document, and later want to include a reference to that document,
>>> the <eref> becomes illegal as soon as I've inserted the reference, and I
>>> would need to manually change the markup to use <relref>.
>> If you believe that is true, it is true today as well for <xref>.
> Umm. The text for <eref> didn't have this limitation earlier, I
> think (my emphasis):
> "A link to URI *that is not in the References section*."
> That's what I understood to be enforcing the necessary change away from
> <eref> if a reference to the same document was added.
Ah! That was not meant to be "enforcing", just helpful, as in "don't do an <eref> if you have something in the References, just do <xref> or <relref>".
>> Personally, I don't think it is true. In the final RFC processing,
>> the RFC Editor might notice that the <eref> is pointing to something
>> in the References, and might ask about changing the <eref> to a
>> <relref> (or, if people want to extend <xref>, to the <xref>).
> 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.
More information about the rfc-interest