[rfc-i] draft-hoffman-xml2rfc-04 - xref/@section
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