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

Re: SVG12: IRI Processing rules and xlink:href (Normalization)

From: Martin Duerst <duerst@it.aoyama.ac.jp>
Date: Thu, 16 Jun 2005 08:57:26 +0900
Message-Id: <6.0.0.20.2.20050616085300.0716ead0@localhost>
To: Chris Lilley <chris@w3.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: "Andrew Sledd" <Andrew.Sledd@ikivo.com>, www-svg@w3.org, public-i18n-core@w3.org

It would be very good if this kind of discussion were at least copied
to public-iri@w3.org (done herewith). This will make sure that when
upgrading RFC 3987 from Proposed to Draft Standard, issues like this
can be taken into account.

Thanks and regards,     Martin.

At 07:13 05/06/16, Chris Lilley wrote:
 >
 >On Monday, June 13, 2005, 9:56:00 PM, Bjoern wrote:
 >
 >BH> * Chris Lilley wrote:
 >>>BH> Yes. And the algorithm defined in RFC 3987 produces different
 >>>BH> results than those defined in XML 1.0, XML Schema 1.0, SVG 1.1, HTML
 >>>BH> 4.01, XML Catalogs, XInclude, XPointer, etc. which produce
 >>>BH> equivalent results.
 >>>
 >>>Because international DNS was not included in the copy paste versions.
 >
 >BH> Well, the difference I am referring to is the incompatibility
 >BH> with the reference character processing model
 >
 >Ah! Thanks for being more specific; the part that I thought you were
 >alluding to and what in fact concerns you turns out to be quite
 >different.
 >
 >BH> as discussed in
 >
 >BH>   http://lists.w3.org/Archives/Public/www-style/2005May/0024
 >
 >BH> This difference was part of the drafts since draft-masinter-
 >BH> url-i18n-02 (published 1998) though the cases in which it
 >BH> applies as well as the requirement levels changed over time.
 >
 >Okay. I see from the link you provided that you have been discussing
 >this on a thread crossposted to www-style@w3.org and
 >public-i18n-core@w3.org - looking at the June archives the thread seems
 >to have died.  Accordingly I have copied public-i18n-core@w3.org on this
 >reply, to get further guidance.
 >
 >Okay, so it comes down to character normalization when non-Unicode
 >encodings are used and the character data has not been normalized.
 >
 >I can see that this is potentially an issue in CSS, but for XML where the
 >only two encodings guaranteed to work across XML parsers are UTF-8 and
 >UTF-16, and where use of any other (non codepoint subset - declaring
 >UTF-8 and then using US-ASCII is not relevant here) encoding has
 >always required declaration of the encoding, this seems to be less of a
 >problem.
 >
 >If I misunderstand, perhaps you could provide a well-formed SVG example
 >derived from one of your CSS examples that illustrates the problem?
 >
 >BH> The other differences are quite unimportant, especially since
 >BH> RFC 3986 takes some of these into account.
 >
 >Yes it does, but thanks again for the clarification.
 >
 >
 >--
 > Chris Lilley                    mailto:chris@w3.org
 > Chair, W3C SVG Working Group
 > W3C Graphics Activity Lead 
Received on Friday, 17 June 2005 06:48:14 GMT

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