This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XQuery syntax generally mimics XML, and we give license to mimic different versions of XML. Test case XML10-5ed-Included-char-1-new in misc-XMLEdition assumes that this means that an XQuery processor that works according to XML 1.1 rules should disallow an unescaped DEL character in a query. However, this seems to be stretching the rules. DEL is a valid Char in XML 1.1; but it is a RestrictedChar, meaning that in XML documents it cannot appear except as a numeric character reference. XQuery allows processors to use either the XML 1.0 or XML 1.1 rules for Char, but it does not explicitly give a processor license to enforce the restrictions associated with a RestrictedChar. Perhaps it should. Or perhaps, for backwards compatibility, it should not.
In last week's telcon, the Working Group agreed to resolve this bug by adopting the XML restriction that control characters cannot appear in unescaped form in an XQuery that's using XML 1.1 rules.
I added the following text to "Constraint: xml-version": XML 1.1 allows the use of character references to the control characters #x1 through #x1F, most of which are forbidden in XML 1.0. Implementations that support XML 1.1 must allow these character references; as in XML 1.1, these characters cannot be used directly. XML 1.0 allowed characters #x7F through #x9F to be used directly in documents, so implementations that support XML 1.0 must also allow these characters to be used directly or as character references. XML 1.1 allows characters #x7F through #x9F only as character references, so implementations that support XML 1.1 must also allow these characters only as character references, they cannot be used directly.
>XML 1.1 allows characters #x7F through #x9F only as character references, so implementations that support XML 1.1 must also allow these characters only as character references, they cannot be used directly. My only quibble with this is the implication that "an implementation that supports XML 1.1" cannot also support XML 1.0. This sentence seems to impose some kind of obligation, which has not previously been present, for processors to support one or the other but not both. Is there an implication here, for example, that if a 1.0 feature (such as the character x80) is used in one module of the query, then a 1.1 feature (such as the character x07) cannot be used in another? I am reopening, because I think this needs further discussion.
(In reply to comment #3) > My only quibble with this is the implication that "an implementation that > supports XML 1.1" cannot also support XML 1.0. This sentence seems to impose > some kind of obligation, which has not previously been present, for processors > to support one or the other but not both. The specification currently says this: <quote src="Appendix D"> The following items in this specification are implementation-defined: ... 6. Whether the implementation is based on the rules of [XML 1.0] and [XML Names] or the rules of [XML 1.1] and [XML Names 1.1]. One of these sets of rules must be applied consistently by all aspects of the implementation. If the implementation is based on the rules of [XML 1.0], the edition used must be at least Third Edition; the edition used is implementation-defined, but we recommend that implementations use the latest version. </quote> I believe the specification already has the requirement you claim was not previously present.
Incidentally, this requirement is also in XQuery 1.0. Of course, an implementation can have an option that determines whether it uses the rules of XML 1.0 or XML 1.1, that would meet the requirement. But it can't be based on the rules of XML 1.0 and XML 1.1 at the same time.
You're interpreting the sentence "One of these sets of rules must be applied consistently by all aspects of the implementation." much more restrictively than I am. Does it mean that the implementation can't have a switch to say whether XML 1.0 rules or 2.0 rules are used? I don't think so. Does it mean it can't have two switches, one for input and one for output (so queries can translate 1.0 input to 1.1 output? Again, I don't think so. (In fact such an implementation is exceeding the requirement: if you apply both sets of rules consistently, then by definition you apply one of them consistently). Similarly, it's still "consistent" to have one rule for queries and another for source documents. If we really intend that all inputs, outputs, and query modules must conform to the same set of rules, and that implementations are not allowed to provide user options to vary this, then we are imposing a quite unnecessary obstacle in the way of interoperability. And in any case, the 3.0 serialization specification explicitly makes the choice for output documents on a per-document basis.
Closing - the remaining part of this is now reflected in Bug 15966.