[rfc-i] draft-hoffman-xml2rfc-04 - xref/@section

Julian Reschke julian.reschke at gmx.de
Thu Mar 20 08:51:31 PDT 2014


On 2014-03-20 16:36, Paul Hoffman wrote:
> On Mar 20, 2014, at 12:48 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
>
>> On <http://tools.ietf.org/html/draft-hoffman-xml2rfc-04#section-2.58.3>:
>>
>>> 2.58.3. 'section' attribute
>>>
>>>
>>>    Specifies a section for the generated reference.  For example,
>>>
>>>         See <xref section="2.3" target="RFC6949"/> for more inforation.
>>>
>>>    would generate
>>>
>>>         See Section 2.3 of [RFC6949] for more information.
>>
>> I appreciate the addition, but I think we need a bit more:
>>
>> - the impact on non-reference xrefs should be mentioned (ignored/invalid?)
>
> Let's go for "invalid" on all target attributes that don't exist; that will reduce surprise for authors.
>
>> - I believe we need to support at least one additional format, being: "[RFC6949], Section 2.3"
>
> Yes, that seems like a reasonable presentation requirement. But there will be many others, such as:
>
>> - the ability to specify a relative reference (to be resolved against the linked-to document's base URI), so that we can "deep link" into non-IETF documents (see <http://greenbytes.de/tech/webdav/draft-reschke-xml2rfc-latest.html#element.rfc.attribute.xml-lang> for an example use)
>
> I'm not happy with that one, because it opens the RFC up to conflicting semantics: the relative reference might not actually be to the same document as the xref.

Not sure what you are referring to.

The link in the generated HTML for a vanilla xref to a reference should 
go the entry in the references section.

The reference itself can have a @target attribute. My proposal is to 
result the relative reference against that target URI. So in general the 
resulting target for the section reference would be a child/secondary 
resource of the target (and yes, we could automatically test that).

>> PS: see also <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref>
>
> I'm sure someone will want something other than what is there for x:fmt, but it is certainly better than the fixed wording in the current draft. I'll use that for the next draft unless there are any strong objections.

I would have made a more concrete proposal if my current experimental 
syntax would be nicer. It would be cool if we could select the desired 
format with a single attribute, instead of adding another one (which I 
did because I didn't want to modify RFC2629's format attribute).

Best regards, Julian



More information about the rfc-interest mailing list