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

Henrik Levkowetz henrik at levkowetz.com
Tue Jun 2 08:25:32 PDT 2015


Inline:

On 2015-05-27 08:11, Julian Reschke wrote:
> On 2015-05-27 08:00, Julian Reschke 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.
>>  > ...
>>
>>
>> FWIW, I strongly disagree with this change. I don't believe it helps
>> implementers, and it also makes things harder for authors.
>> ...
> 
> After reading further, I see that I missed additional attributes that 
> weren't mentioned in the introduction.
> 
> So apparently:
> 
>> The frequent idiom of
>>
>>     See Section x of [RFCyyyy]
>>
>> previously was
>>
>>     See <xref section="x" format="of" target="RFCyyyy"/>
>>
>> now becomes:
>>
>>     See <relref section="x" target="RFCyyyy"/> of <xref target="RFCyyyy"/>
> 
> you can use
> 
>        See <relref section="x" sectionFormat="of" target="RFCyyyy"/>
> 
> while in the previous draft you'd have used:
> 
>        See <xref section="x" sectionFormat="of" target="RFCyyyy"/>
> 
> So <xref> was simplified, but <relref> was added which has exactly the 
> same complexity as <xref> with respect to crossreferencing <references>. 
> (It also lost two sectionFormat values, but that's a different story.)
> 
> For authors this means that when they make their <xref> more specific, 
> they need to switch to a different element.

In addition to the added manual work I mentioned in my previous message
regarding <relref>, this point also bothers me.  It again increases the work
one needs to do in order to refine a document, without any added benefit.

> For implementers of tools this means that they have two distinct 
> elements that overlap in functionality.
> 
> I still have no clue how this is better than what we had before.


Regards,

	Henrik

-------------- 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/ea7fa7c0/attachment.asc>


More information about the rfc-interest mailing list