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

Re: SVG12: IRI Processing rules and xlink:href

From: Chris Lilley <chris@w3.org>
Date: Thu, 9 Jun 2005 18:42:39 +0200
Message-ID: <605484577.20050609184239@w3.org>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: "Andrew Sledd" <Andrew.Sledd@ikivo.com>, www-svg@w3.org

On Wednesday, June 8, 2005, 9:26:30 PM, Bjoern wrote:


BH> * 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?

BH> Hi Andrew, I trust the SVG Working Group will formally address all
BH> your comments on SVG 1.2 and update the draft in response to them,
BH> but as the answers from Mark and Jon on this issue weren't really
BH> correct, I guess someone should clarify the situation.

BH> The most important thing here that both Mark and Jon missed is that
BH> the draft refers to IRI References as defined in RFC 3987 for the
BH> xlink:href attribute,

yes

BH> not to "URIs" or "relative URIs" as defined (or not) in RFC 2396.

Yes. It also refers to RFC 3986, which you perhaps missed.

BH> (XLink 1.0, which defines xlink:href, refers to RFC 2396 though, SVG
BH> Tiny 1.2 is not compatible with XLink 1.0 or SVG 1.1 in this regard)

This oversimplifies. The XLink 1.0 href attribute does not contain an
RFC 2396 URI. It contains a string (what would nowadays be called an
IRI) which is processed to produce a URI (which is nowadays defined by
RFC 3986). So the difference here is that SVG 1.2 defines the process of
converting an IRI to a URI by reference to the URI specification; while
SVG 1.1 (and XLink 1.0, and XML Schema) all had copy and paste versions
of that conversion process as there was no stable IRI specification to
refer to at that time.

BH> Under RFC 2396 the empty string would be neither a "URI" (RFC 2396
BH> does not actually define that term) nor a "relativeURI" (which, as
BH> Jon points out, must be non-empty) or a "absoluteURI" (which must be
BH> non-empty aswell). The correct term would be "URI-Reference" which
BH> is defined as

BH>   URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

Yes.

BH> RFC 3986, which obsoletes RFC 2396, changes various things here. First,
BH> URI-References are now defined as

BH>   URI-reference = URI / relative-ref

BH> the term URI (now defined) is an absoluteURI with an optional fragment
BH> identifier (not allowed for absoluteURI in RFC 2396)

or in other words, the fragment identifier was previously part of a
URI-Reference but not part of the URI.

BH> and "relative URIs" do not exist anymore, they are now called
BH> "relative references" to avoid confusion (people assume that a
BH> "relative URI" would be a special kind of "URI" but they are not).

Right.

BH>  A Relative reference may also have the
BH> optional fragment identifier (not allowed for relativeURI in RFC 2396).

Yes.

[snipping the parts already dealt with in this thread]


-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
Received on Thursday, 9 June 2005 16:42:49 GMT

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