RE: SVG12: IRI Processing rules and xlink:href

Mark,
Thanks!
Jon

At 04:03 AM 6/8/2005, Mark Birbeck wrote:
>Hi Jon,
>
>I'm reading my email in reverse order, so I don't know what the context of 
>this discussion is!
>
>However, an empty string *is* a valid relative URI, and it does mean the 
>current document. This is common practice, particularly in the RDF world.
>
>The part that you quoted from RFC 2396 (step 6a of section 5.2) is too far 
>into the resolution algorithm, and assumes that the path component is not 
>empty. However, your algorithm should have stopped way earlier, at step 2 
>since the path *is* empty. (See also section C.2 for a more explicit 
>reference to this.)
>
>Regards,
>
>Mark
>
>
>Mark Birbeck
>CEO
>x-port.net Ltd.
>
>e: Mark.Birbeck@x-port.net
>t: +44 (0) 20 7689 9232
>w: <http://www.formsplayer.com/>http://www.formsPlayer.com/
>b: <http://internet-apps.blogspot.com/>http://internet-apps.blogspot.com/
>
>Download our XForms processor from
><http://www.formsplayer.com/>http://www.formsPlayer.com/
>
>
>
>----------
>From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of 
>Jon Ferraiolo
>Sent: 07 June 2005 20:12
>To: Andrew Sledd; www-svg@w3.org
>Subject: Re: SVG12: IRI Processing rules and xlink:href
>
>At 04:40 AM 6/7/2005, Andrew Sledd wrote:
>>Hello,
>>The processing of references (section 14.1) seems clear in its 
>>presentation but is a bit convoluted in practice, especially when 
>>combined with error processing. It appears to me that the SVG spec only 
>>sets restrictions on the resultant reference. The SVG spec defers 
>>completely to the IRI/URI reference for requirements on reference resolution.
>>
>>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?
>>
>>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).
>
>Andrew,
>I think xlink:href="" is an error. The attribute definition references RFC 
>2396 [http://www.faqs.org/rfcs/rfc2396.html]. Reading through that RFC, 
>when you get to relative URIs in section 5, it says:
>
>
>rel_path      = rel_segment [ abs_path ]
>
>rel_segment   = 1*( unreserved | escaped |
>
>
>
>";" | "@" | "&" | "=" |
>
>"+" | "$" | "," )
>
>The key thing is the "1*", which looks to me as if there must be at least 
>one character in a relative URI.
>
>Furthermore, even if "" were a valid relative URI, then I contend it would 
>still not reference the document itself. To illustrate, let's say the 
>current document has a URI of http://example.com/foo.svg. Then according 
>to section 5.2 of RFC 2396, step 6a, for relative URI processing, it says:
>
>
>          All but the
>
>last segment of the base URI's path component is
>
>          copied to the
>
>buffer.  In other words, any characters after the
>
>          last (right-most) slash
>
>character, if any, are excluded.
>
>Therefore, assuming for the moment that it is not error, an attribute 
>value of xlink:href="" would resolve to "http://example.com/", not 
>"http://example.com/foo.svg".
>
>But there are greater URI experts around. (I am surprised none of them 
>have spoken up so far.)
>
>Jon
>
>
>>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.
>>
>> From this I conclude that xlink:href="" to be invalid and put the 
>> document in error
>
>>a) for <use> and <animation>; except in the case where its resolved 
>>xml:base breaks this inherent circular reference
>>b) for <image>; except in the case where its resolved xml:base is a 
>>non-local reference
>>
>>Is this reasoning correct?
>>
>>Regards,
>>Andy Sledd
>>
>>_______________________________________
>>Andrew Sledd
>>Ikivo AB

Received on Wednesday, 8 June 2005 14:57:24 UTC