RE: escape-uri-attributes

> So, I think I agree with you. I can't see any reason why all URIs
> serialised by XSLT shouldn't be escaped according to the rules in the
> XLink Rec, and don't understand the requirement for the
> escape-uri-attributes attribute.
> 
> Perhaps one of the WG could explain?
> 
I think we might not have considered this quite as carefully as we might.
It's just one of those areas where users often have problems with the
facility as provided, and giving them the ability to switch it off seems
reasonable, for example if they are generating code for HTML or XHTML
clients that aren't fully conformant, or if they're generating something
that isn't actually an HTML page at all (e.g. it might be ASP), or if they
know that the URI's are already correctly escaped, or if they want to
substitute their own escaping logic that behaves differently (e.g. by
escaping special ASCII characters as well as non-ASCII characters).

RFC 2396 says: "Data must be escaped if it does not have a representation
using an
   unreserved character; this includes data that does not correspond to
   a printable character of the US-ASCII coded character set".

I suspect therefore that it is incorrect for XSLT to say that "non-ASCII
characters" should be escaped. I haven't checked the US-ASCII spec (ANSI
X3-1984) but I assume that space is classified as a non-printable character
and that spaces should therefore be escaped under the RFC 2396 rules. (Other
ASCII non-printables come under the definition of "control characters" which
are not allowed in URIs anyway). My main reservation about escaping spaces
is that it would apply to the fragment identifier in <A HREF="">, and this
might cause the fragment not to match the identifier in <A NAME="">, (or
ID="") which is NOT currently escaped, because it is not a URI (and which in
XHTML cannot be escaped, because it is an ID, and an ID cannot contain a "%"
sign).

All this seems to indicate that some degree of pragmatism is called for...

Mike Kay

Received on Monday, 28 January 2002 10:40:11 UTC