Re: SVG12: IRI Processing rules and xlink:href

Bjoern,
Thanks once again for your help.

Jon

At 12:26 PM 6/8/2005, Bjoern Hoehrmann wrote:

>* Andrew Sledd wrote:
> >I have a question about interpretation and reference resolution, in
> >particular about the reference xlink:href="". What does the reference
> >resolve to? Is it valid for image in the SVG Tiny Profile? Is it valid
> >for use and animation in the SVG Tiny Profile?
>
>Hi Andrew, I trust the SVG Working Group will formally address all your
>comments on SVG 1.2 and update the draft in response to them, but as the
>answers from Mark and Jon on this issue weren't really correct, I guess
>someone should clarify the situation.
>
>The most important thing here that both Mark and Jon missed is that the
>draft refers to IRI References as defined in RFC 3987 for the xlink:href
>attribute, not to "URIs" or "relative URIs" as defined (or not) in RFC
>2396. (XLink 1.0, which defines xlink:href, refers to RFC 2396 though,
>SVG Tiny 1.2 is not compatible with XLink 1.0 or SVG 1.1 in this regard)
>
>Under RFC 2396 the empty string would be neither a "URI" (RFC 2396 does
>not actually define that term) nor a "relativeURI" (which, as Jon points
>out, must be non-empty) or a "absoluteURI" (which must be non-empty
>aswell). The correct term would be "URI-Reference" which is defined as
>
>   URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
>
>RFC 3986, which obsoletes RFC 2396, changes various things here. First,
>URI-References are now defined as
>
>   URI-reference = URI / relative-ref
>
>the term URI (now defined) is an absoluteURI with an optional fragment
>identifier (not allowed for absoluteURI in RFC 2396) and "relative URIs"
>do not exist anymore, they are now called "relative references" to avoid
>confusion (people assume that a "relative URI" would be a special kind
>of "URI" but they are not). A Relative reference may also have the
>optional fragment identifier (not allowed for relativeURI in RFC 2396).
>
>RFC3987 refers to such references as "Relative IRI References". Relative
>IRI References are resolved to IRIs as defined in RFC 3986 for relative
>references. The empty string would basically resolve to the absolute-IRI
>part of the "base IRI". So your interpretation
>
> >I interpret the specs (SVG 1.2/IRI/URI) to say as follows:
> >1) xlink:href="" resolves to a reference to the document itself (if no
> >other xml:base attribute is explicitly given in the ancestors to the
> >referencing element).
>
>is not really correct either. Consider an example like
>
>   <!-- document at http://example.org/svg/svg -->
>   <g xml:base="http://example.org/base">
>     <image xlink:href="" ... />
>   </g>
>
>In this case the xlink:href would resolve to <http://example.org/base>,
>so e.g. getTraitNS('http://www.w3.org/1999/xlink', 'href') will return
>an IRI canonically equivalent to that. This means the fragment above is
>basically equivalent to
>
>   <!-- document at http://example.org/svg/svg -->
>   <g xml:base="http://example.org/base">
>     <image xlink:href="http://example.org/base" ... />
>   </g>
>
>Part of your conclusion is correct though,
>
>   When a URI reference refers to a URI that is, aside from its
>   fragment component (if any), identical to the base URI (Section
>   5.1), that reference is called a "same-document" reference.
>
>same-document references should not cause new retrievel action, so
>the IRI would dereference to the document that includes the xlink:
>href attribute. Whether a reference is a same-document reference is
>not affected by xml:base or its lexical representation though.
>
> >2) In terms of IRI processing (Section 14.1.1) this is both a local
> >reference and for the scope of <image> and <use> is an indirect circular
> >reference.
>
>I'm afraid there are too many errors in the draft to tell what the
>Working Group might have had in mind here.
>--
>Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
>Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
>68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 8 June 2005 21:06:18 UTC