[Bug 9900] New: XML10-5ed-Included-char-1

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

           Summary: XML10-5ed-Included-char-1
           Product: XML Query Test Suite
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XML Query Test Suite
        AssignedTo: andrew.eisenberg@us.ibm.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


This test contains a DEL character (x7F) within a direct element constructor,
and permits the error XPST0003. The test metadata contains the description:

Contains a DEL, legal in XML 1.0, illegal in XML 1.1.

First problem: this comment is a simplification of the rules. XQuery allows any
Char to appear in the content of a direct element constructor, and defines Char
by reference to the relevant production rule in the XML specification. XML 1.0
(all editions) contains the production rule:

[2]       Char       ::=       #x9 | #xA | #xD | [#x20-#xD7FF] | ...

while XML 1.1 has

[2]       Char       ::=       [#x1-#xD7FF] |  ...

In both, the production rule Char allows x7F. It's true that XML 1.1 has a rule
saying that x7F is a RestrictedChar which means it can only appear in element
content if written as a character reference. But this test uses x7F in an
XQuery direct element constructor, not in an XML document. XQuery allows you to
use either definition of Char, but it does not allow you to say "direct element
constructors in XQuery are supposed to look a bit like elements in XML, so I
will adopt the rules about not allowing RestrictedChar to appear". So I think
this query should not permit the error case: the query is legal, regardless
what version of XML you support.

Second problem: I hit upon this because the Saxon test driver was producing
results, but failing to compare them with the reference results because of a
failure in the canonicalizer. This was caused by using an XML 1.1 parser to
compare the results, which fails because the expected results file contains a
DEL character written as a literal character, not as a numeric character
reference. I think it would be desirable if the expected results file can be
parsed by an XML 1.1 parser, and it should therefore use a numeric character
reference & # x 7 f ; here.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 10 June 2010 12:40:36 UTC