[rfc-i] New Version Notification for draft-hoffman-xml2rfc-18.txt

Paul Hoffman 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
>> rendered.
> 
> 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.

--Paul Hoffman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20150602/8a1f1863/attachment.asc>


More information about the rfc-interest mailing list