W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2010

[Bug 11585] New: [XQ 3.0] Non-Schema-Aware XQuery processors: conformance rules

From: <bugzilla@jessica.w3.org>
Date: Tue, 21 Dec 2010 10:11:43 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-11585-523@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11585

           Summary: [XQ 3.0] Non-Schema-Aware XQuery processors:
                    conformance rules
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3.0
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


We define two optional features: the schema import feature, and the validation
feature.

My first comment is: isn't it possible to combine these into one? It would be
useful to see whether there are any XQuery 1.0 processors that have implemented
one of these features but not the other. If we can simplify the number of
conformance permutations, we can increase interoperability.

My second comment is: we don't actually say as much, but it's very likely that
a product that doesn't implement either of these features will treat all input
documents as untyped (that is, elements as xs:untyped and attributes as
xs:untypedAtomic). This of course makes life very much easier for
implementations: there's no need to actually have a type annotation stored in
the node, and the string value of a node is always the same as the typed value.

However, there's one glitch that means this doesn't quite work. A product that
doesn't support either the schema import feature or the validation feature is
still required to support construction mode preserve, and in construction mode
preserve, new elements have type xs:anyType rather than xs:untyped. There is
almost no difference in the behaviour of xs:anyType elements versus xs:untyped
in the situation where all the descendants are also anyType/untyped, but the
processor needs to retain the difference because it affects "instance of" and
"typeswitch".

So I would like to propose a change in the definition of the "validation
feature" so that a product that does not support this feature also does not
support construction mode preserve. This means that it can truly treat all
elements as untyped.

Alternatively, we could say that a processor can label nodes created using
construction mode preserve as xs:untyped if it is able to determine that all
the descendants will be untyped.

-- 
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 Tuesday, 21 December 2010 10:11:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:44 UTC