This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It seems to me the [FS] section 8.2.3.1.1 Name Tests is buggy. a) When the name test contains a non-wildcard prefix or local name, while the element name of the element type is a wildcard, the resulting type should be optional because during evaluation the expressions value may or may not match. Therefore, in the following three judgments statEnv |- test QName2 with element of element * statEnv |- test *:LocalPart2 with element of element * statEnv |- test Prefix2:* with element of element * the result type should receive a ?. Shouldn't it? b) In the judgment statEnv |- test *:LocalPart2 with element of element QName1 the conditions statEnv.namespace(Prefix1)=(NamespaceKind,AnyURI) fn:namespace-uri-from-QName(expandedQName1) = AnyURI should be removed. (In fact they ascertain that the prefix of the element type is mapped onto a namespace URI, rather than onto the null namespace why? Also compare the corresponding attribute rule why should they differ?) c) In the judgment statEnv |- test *:Prefix2:* with element of element QName1 condition #2 should reference Prefix2, not Prefix1. d) In my optionion, the judgment producing the empty type result is not appropriate. (1) As the name test is indeed a pure name test, ignoring any type annotations as far as checking is concerned, it is unclear how one can base the judgment on any conditions posed on the element types type annotation. (2) As TypeSpecifier1 is of type xs:anyType, the judgment statEnv |- not (Type2 <: Type1) simply never holds. (3) The current version of the judgment amounts to equating a name test to a kind test (ElementTest) containing a type annotation of xs:anyType. But a kind test is based on matching types, a name test solely on matching names. If the element name of the element type is member of a substitution group, a kind test can match while the corresponding name test cannot. (4) I propose to replace the current judgment for empty result by two judgments, one based on mismatching namespace URIs, the other on mismatching local names.
(personal response) Part a: (rules 2,5,7) Agreed. (This is actually a duplicate of the 'element' half of Bug 4242.) Part b: (rule 4) I agree: the extra premises require that the element name of the thing-being-tested have a namespace URI that is bound to a prefix in the static environment. Not only does this exclude the case where the element name is not in a namespace (as the submitter points out), but it also excludes the case where its namespace is the default element namespace (and not bound to any prefix). As far as I can tell, both of these exclusions are incorrect. Part c: (rule 6) Agreed. Part d: (rule 17) Agreed, except that I think we need to replace it with three rules, not two: statEnv |- QName1 of elem/type expands to expanded-QName1 statEnv |- QName2 of elem/type expands to expanded-QName2 not( expanded-QName1 = expanded-QName2 ) --------------------------------------------------------- statEnv |- test QName2 with element of element QName1 OptTypeSpecifier1 : empty statEnv |- QName1 of elem/type expands to expanded-QName1 fn:local-name-from-QName(expanded-QName1) = LocalPart1 not( LocalPart1 = LocalPart2 ) --------------------------------------------------------- statEnv |- test *:LocalPart2 with element of element QName1 OptTypeSpecifier1 : empty statEnv |- QName1 of elem/type expands to expanded-QName1 fn:namespace-uri-from-QName(expanded-QName1) = AnyURI1 statEnv.namespace(Prefix2) = (NamespaceKind,AnyURI2) not( AnyURI1 = AnyURI2 ) --------------------------------------------------------- statEnv |- test Prefix2:* with element of element QName1 OptTypeSpecifier1 : empty (And, of course, all three will need 'attribute' counterparts.)
[Personal comment] The original description asks In fact they ascertain that the prefix of the element type is mapped onto a namespace URI, rather than onto the null namespace why? Also compare the corresponding attribute rule why should they differ? Any prefix in a QName is required to map to a namespace URI and not to the null namespace; it's a requirement of the Namespaces Recommendation. And the treatment of QNames as element names and attribute names does need to differ in the sense that unprefixed attribute names invariably are unqualified, whereas unprefixed element names can have a non-null namespace URI (the default namespace). I am told that these arguments do not in fact mean that the two conditions in queston should be retained. But I'd like the correction of the rules to be based on correct interpretation of the namespaces Rec.
(Personal response) Consider the third premise: fn:namespace-uri-from-QName(expandedQName1) = AnyURI If expandedQName1 were in no namespace, then the result of fn:namespace-uri-from-QName() would be the zero-length string. But the empty string is not in the value-space of AnyURI, so the premise would not be satisfied. Thus, this premise requires that expandedQName1 be in a namespace. This also implies (somewhat indirectly) that, if QName1 has a prefix, then that prefix must map to a namespace URI (and not the null namespace). While the latter restriction agrees with the namespaces Rec, it is achieved by over-constraint: it is incorrect to require that expandedQName1 be in a namespace. (And then the second premise makes it even worse by requiring that the namespace be in the statically known namespaces, but that's beside your point.) So we cannot retain either of these premises. You might wonder if it would be possible to replace them with premises that achieve the prefix/namespace restriction without over-constraint. Certainly it would be possible, but I don't think it would be appropriate. (If here, then why not every other place where an "element QName" type appears?) Instead, I think the appropriate way to enforce the prefix/namespace restriction would be to remove the possiblity of statEnv.namespace mapping a prefix to #NULL-NAMESPACE (in FS 3.1.1 and 3.1.1.1 / Semantics / rules 1 and 3). Theoretically, I believe we're "safe" because the FS doesn't actually provide a way to _achieve_ such a mapping (see Bug 1542, Comment #1 and #3), but that's a) not very obvious, and b) not very reassuring.
The working groups have approved the solutions given in Comment #1. Consequently, I am marking this bug FIXED. Please indicate your acceptance of this resolution by marking the bug CLOSED.
Thanks for considering and commenting on this issue. Marking the bug as Closed now. Regards - Hans-Juergen Rennau
This issue has been incorporated into FS erratum E018, whose fix has been committed to the source files for the next edition of the FS document.