W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2006

[Bug 2441] xqx: character references

From: <bugzilla@wiggum.w3.org>
Date: Fri, 29 Sep 2006 07:37:32 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1GTCw8-0005SW-4S@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=2441





------- Comment #17 from mike@saxonica.com  2006-09-29 07:37 -------
I'm puzzled that you don't find the XQuery spec clear on the subject of how
predefined entity references are handled. It seems eminently clear to me. 

There are three places they can occur: in string literals, in attribute
content, and in element content.

For string literals, section 3.1.1 spells out the rules and seems entirely
clear.

For attribute content, rule 1 says "Attribute value normalization is then
applied to normalize whitespace and expand character references and predefined
entity references. " This spells out the rules by reference to the XML
specification (which describes the interaction of entity expansion and
whitespace normalization): the rules are complicated, but I think they are
unambiguous.

For element content, section 3.7.1.3 rule 1b gives the rules by reference to
the rules in 3.1.1 for string literals.

So what exactly is it that you think isn't stated clearly in the XQuery
specification?

(You alleged that one implementation did double-expansion of entity references,
turning &amp;&lt; into a less-than-sign. I think it's quite clear in the XQuery
spec that processors mustn't do that. If you're in element content, for
example, no possible reading of section 3.7.1.3 would allow that
interpretation. In any case, as David Carlisle points out, common sense should
give you the same answer: if an ampersand written as &amp; were treated in the
same way as one written as &, why would the specification bother to provide a
way of escaping the character in the first place?)

Michael Kay
Received on Friday, 29 September 2006 07:37:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:15 UTC