Re: escape-uri-attributes

Hi Werner,

> As a consequence, I think URIs should always be serialised in
> escaped form, otherwise you're not serialising URIs. I therefore
> fail to see to the use of the escape-uri-attributes attribute. Also
> in HTML and XHTML URIs must be in escaped form, otherwise they are
> not URIs and validation should fail. Only the processor of the HTML
> or XHTML file may unescape an URI during some kind of
> interpretation.

Hmm... this is a tricky area. The XLink Rec and the XML Schema
Datatypes Rec imply that partially-escaped URIs can be the lexical
values of xs:anyURI attributes (e.g. xlink:href). By partially
escaped, I mean that XML Schema and XLink will accept URIs in which
non-ASCII characters and some disallowed characters are not escaped.
See http://www.w3.org/TR/xlink/#link-locators for an exact
description.

I think that the effect of the escaping rules from XLink and XML
Schema is that if you read in a partially-escaped xs:anyURI value,
then escaped it according to those same rules, then you'd get the same
xs:anyURI value - you don't get double-escaping problems because %
isn't amongst the disallowed characters that are escaped according to
the XLink rules.

I didn't have a clear idea of why escape-uri-attributes was required
for HTML and XHTML output methods in the first place (I just thought
that if it's relevant for them then it's probably relevant for the XML
output method too). Then I thought it might be to avoid
double-escaping. But now I don't understand again - the XSLT 2.0 WD
only talks about escaping non-ASCII characters (not all disallowed
characters), so presumably processors shouldn't escape % signs anyway,
and double-escaping isn't an issue.

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?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Friday, 25 January 2002 18:37:23 UTC