W3C home > Mailing lists > Public > www-svg@w3.org > June 2005

RE: SVG12: IRI Processing rules and xlink:href

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 8 Jun 2005 12:03:36 +0100
Message-ID: <9114A666-41BD-4B29-A7EA-BC03C5AE476E@S009>
To: "'Jon Ferraiolo'" <jon.ferraiolo@adobe.com>
Cc: "'Andrew Sledd'" <Andrew.Sledd@ikivo.com>, <www-svg@w3.org>
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/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
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 11:05:55 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:30 GMT