This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1330 - escaping and non-ascii-characters
Summary: escaping and non-ascii-characters
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Serialization 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P3 normal
Target Milestone: ---
Assignee: Scott Boag
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-11 03:00 UTC by Felix Sasaki
Modified: 2005-05-30 09:01 UTC (History)
0 users

See Also:

Attachments

Comment 1 Michael Kay 2005-05-11 07:56:00 UTC 
Escaping restricted ASCII characters in URIs would be a disaster in practice.
Whatever the W3C specs say, we have to accommodate practical reality, and the
reality on the ground is that attributes that are supposed to hold URIs
frequently contain bits of client-side JavaScript code which will not execute
correctly on popular browsers if escaped. If you want your XSLT 2.0 processor to
be accepted by users, generating HTML that's incompatible with installed
browsers is not the way to do it.

Even escaping of non-ASCII characters causes problems in some cases, for example
in the fragment identifier of an href attribute: it creates a fragment id that's
not a valid NCName (because it contains % signs) and that doesn't match up with
the anchors in the document (which are not % escaped). Browsers do not unescape
the URI if it's used client-side. This problem is bad enough already without
making it worse.

Michael Kay (personal response)
Comment 2 Felix Sasaki 2005-05-30 09:01:43 UTC 
consensus of the i18n-core-wg, telecon 27 may 2005: closed.