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

Henrik Levkowetz henrik at levkowetz.com
Tue Jun 2 11:14:56 PDT 2015


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
>>> 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>.

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.

> 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.

>> 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.

The difference is in my understanding of the added <eref> text -- that limitation
wasn't in v2, I think.

>> 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.

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?


Regards,

	Henrik


> 
> --Paul Hoffman
> 
> 
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20150602/e70d769e/attachment.asc>


More information about the rfc-interest mailing list