Marking this as XPath, but it actually applies to XSLT and XQuery because that's where the conformance rules appear.
In a non-schema-aware product (varying the terminology between XSLT and XQuery as necessary), all element nodes have the type annotation xs:untyped, and no element nodes have the nilled property. The conformance rules don't prohibit the use of an item type of the form element(N, T), provided that T is a built-in (schema) type. This construct is essentially useless in a non-schema-aware product, but it seems that such a product has to go to considerable lengths to implement it correctly. As far as instance matching is concerned, an instance is always matched when T is xs:anyType, xs:anyType?, xs:untyped, or xs:untyped?, and it is never matched for all other values of T. So one might expect that a non-schema-aware product merely has to classify T as "always matched" or "never matched".
The complication is the itemType-subType rules which affect whether one type is a subtype of another. These require, for example, that element(N, xs:anyType) is treated differently from element(N, xs:anyType?) despite the fact that in a non-schema-aware product, they have exactly the same set of instances. (In practice the subtype rules only affect higher order functions).
I think it would be much more sensible for a non-schema-aware product to reject the constructs element(N, T) and attribute(N, T) entirely.
Marking this as XPath, but it actually applies to XSLT and XQuery because that's where the conformance rules appear.
In a non-schema-aware product (varying the terminology between XSLT and XQuery as necessary), all element nodes have the type annotation
xs:untyped, and no element nodes have the nilled property. The conformance rules don't prohibit the use of an item type of the formelement(N, T), provided that T is a built-in (schema) type. This construct is essentially useless in a non-schema-aware product, but it seems that such a product has to go to considerable lengths to implement it correctly. As far as instance matching is concerned, an instance is always matched when T isxs:anyType,xs:anyType?,xs:untyped, orxs:untyped?, and it is never matched for all other values of T. So one might expect that a non-schema-aware product merely has to classify T as "always matched" or "never matched".The complication is the itemType-subType rules which affect whether one type is a subtype of another. These require, for example, that
element(N, xs:anyType)is treated differently fromelement(N, xs:anyType?)despite the fact that in a non-schema-aware product, they have exactly the same set of instances. (In practice the subtype rules only affect higher order functions).I think it would be much more sensible for a non-schema-aware product to reject the constructs
element(N, T)andattribute(N, T)entirely.