[rfc-i] New Version Notification for draft-hoffman-xml2rfc-18.txt
paul.hoffman at vpnc.org
Tue Jun 2 08:59:09 PDT 2015
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>. 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>).
> It seems to me that this imposes manual change work that is quite unnecessary;
> it would be more helpful if one could use the same markup irrespective of
> whether a reference is present or not. It is my impression from what the
> document (-18) says that the resulting external link would be the same
> with <eref> and <relref>, so the effect of limiting the use of <eref>
> to URIs that are _not_ in the references section seems to have no benefit,
> only the drawback of enforcing unnecessary manual work.
I'm not sure how you got that impression; it is certainly not what was intended with the words above, or the words in the v2 spec.
> I don't have any strong views on how helpful it would be to be able to
> specify external links relative to a reference entry, except that if one
> uses <relref> and then removes the reference in question, one again gets
> to do manual work in changing <relref> back to <eref>. Also here I'd prefer
> to simply make the presence of absence of any given reference irrelevant
> for how an external link is expressed.
That seems fine. It would be an editorial call, not part of the vocabulary, whether to disallow <eref> to something that is in a Reference.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the rfc-interest