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.
>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.
Arguably this is a clarification rather than a substantive change, under the dictum that where the spec says a construct must return a value of type T, it is always legal to return a value that belongs to a subtype of T: so if it says the result is an element(*, xs:anyType) then returning element(*, xs:untyped) is permissible.
I am very much in sympathy with the content of this message.
This bug will not be considered until shortly before the XQuery 3.0 spec enters Last Call, at which time this and other conformance-related issues will be addressed.
Minimal Conformance does not require an implementation to support
"declare construction preserve".
We add an Optional Feature called "Construction Preserve". If
"Construction Preserve" is not enabled, an error is raised if the user
attempts to declare construction preserve. (We should probably combine
this with one or more other features related to schema types - and we
should have a NOTE that says that - but that's orthogonal, and we can
decide how to bundle optional features later.)
The feature name is "construction-preserve". This can be used in
require-feature / prohibit-feature.
The WG has consensus for the approach in comment #4 - we are leaving this open for our consideration of conformance later.
(In reply to comment #5)
> The WG has consensus for the approach in comment #4 - we are leaving this open
> for our consideration of conformance later.
It seems unfortunate that a bug report which started with the aspiration to combine two optional features into one should instead result in them being divided into three... We should avoid proliferation of options if we want to achieve the goal of interoperability.
(In reply to comment #6)
> (In reply to comment #5)
> > The WG has consensus for the approach in comment #4 - we are leaving this open
> > for our consideration of conformance later.
> It seems unfortunate that a bug report which started with the aspiration to
> combine two optional features into one should instead result in them being
> divided into three... We should avoid proliferation of options if we want to
> achieve the goal of interoperability.
Perhaps you missed this part:
(We should probably combine this with one or more other features related to schema types - and we should have a NOTE that says that - but that's orthogonal, and we can decide how to bundle optional features later.)
We haven't decided on the final number or configuration of optional features, which is why we left the bug open. I think the wording from the resolution shows sympathy for your concern.
The Working Group decided that Non-Schema-Aware XQuery processors treat all elements as untyped, all attributes as untypedAtomic.
I am reopening this because the resolution does not appear to be reflected in the current draft.
The decision that "that Non-Schema-Aware XQuery processors treat all elements as untyped, all attributes as untypedAtomic." doesn't appear to be reflected in section 5.2.1|3 "Schema-Aware Feature", or anywhere else as far as I can tell.
See test K2-DirectConElemContent-35 which does
<e/> instance of element(*, xs:untyped)
and expects the result false. I think it's a consequence of our decision that a non-schema-aware processor should return "true" for this test. I would like to change the test accordingly, but I don't think we can do so based on the spec as currently written.
(In reply to comment #9)
> I am reopening this because the resolution does not appear to be reflected
> in the current draft.
That's because it was removed from the current draft as a result of the face-to-face meeting in Lyon, where we discussed this point explicitly.
As the the minutes record:
jonathan:5.2.3 Schema Aware Feature
[4:29pm]jonathan:proposal: schema aware allows/prohibits schema import
and validate, nothing more or less
[4:30pm]jonathan:different modules may enable/disable this feature in a
We discussed this at the face-to-face, in our resolution of Bug 19602, which records the same decision.
There is no suggestion in the minutes that the WG reconsidered the arguments in this thread and chose to change its carefully-reached conclusions.
This thread primarily concerns the behaviour of "non schema aware processors". The other thread primarily concerns the semantics of "non schema aware modules". The two things are (or should be) related, but they are not the same thing, and a decision reached about the one does not automatically reverse a decision reached about the other.
Closing. The part that still needs to be done is in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20828