W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

Re: SVG12: <iri>

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sun, 29 Jan 2006 19:33:23 +0100
To: Chris Lilley <chris@w3.org>
Cc: www-svg@w3.org, Felix Sasaki <fsasaki@w3.org>
Message-ID: <4v1qt1tl7a06e548cneufptsicn07e3j09@hive.bjoern.hoehrmann.de>

* Chris Lilley wrote:
>BH> It is also unclear how SVG Tiny 1.2 is in a position to re-define
>BH> normative dependencies like CSS 2.0 which does not allow anything
>BH> but URIs in the url() notation,
>Looking at the normative reference in CSS 2.0
>    "Uniform Resource Identifiers (URI): Generic Syntax and Semantics",
>    T. Berners-Lee, R. Fielding, L. Masinter, 18 November 1997.
>    Available at
>    http://www.ics.uci.edu/pub/ietf/uri/draft-fielding-uri-syntax-01.txt.
>    This is a work in progress that is expected to update [RFC1738] and
>    [RFC1808].

I fully agree with the SVG Working Group that CSS 2.0 is not a good
normative reference for the definition of the url() functional notation
and CSS 2.1 should be the normative reference instead. The latest draft
does not include this change, though. Please correct this mistake by
referring to CSS 2.1 in a way that makes it clear that SVG Tiny 1.2 does
not re-define CSS 2.1's definition of url() but rather just re-uses it.

>BH>  and other specifications like xml:base and XLink 1.0
>BH> do not use IRIs either
>Their definition predates the issuing of RFC 3987 but they were intended
>to use the same syntax. Now that RFC 3987 has been issued,
>specifications are being updated to remove the copy-paste versions of
>the escaping mechanism and to refer to RFC 3987 directly. SVGT 1.2 does
>this also.

The XML Core Working Group rather intends to introduce the term XML
Resource Identifier, which is a string that can be converted to IRI
Reference, which is copied and pasted across all their technical re-
ports, as I understand it. So no, you aren't doing what other groups
are doing. Due to this SVG 1.2's xlink:href and XLink's xlink:href
are incompatible, for example. I've explained this in another comment
in more detail.

>BH>  (and IRIs are incompatible with their URI I18N mechanisms).
>We find that this is not the case, and that considerable liaison effort
>took place between the authors of RFC 3986 and RFC 3987 to ensure that
>they were compatible.

That's irrelevant to my analysis above, I didn't mention RFC 3986
at all, for example.

>BH> Please change the draft such that there are different data
>BH> types for IRI literals and IRIs in url()
>We decline to do so,

The Working Group then probably misunderstood my request, please read it
again and let my know which changes the Group is going to make such that
<iri> does not refer to a plain resource identifier and url(...) at the
same time.
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 Sunday, 29 January 2006 18:32:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:06 UTC