This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XQuery allows arbitrary, implementation defined, inference rules, as per 5.2.3.1 Static Typing Extensions. It also says that XPST0005 should be raised on any expression that has as static type the empty sequence: "During the analysis phase, it is a static error if the static type assigned to an expression other than the expression () or data(()) is empty-sequence()." When combining these two, it is possible for an implementation to raise XPST0005 on any expression that evaluates to the empty sequence. The only limit is on what the implementation manages to infer. I don't know if I'm here arguing a theoretic point which in practice is irrelevant, but this stems from member-query-test where a member indeed wanted to raise XPST0005 in such a case(path expression missing on a direct element constructor). Should it really be implementation defined what expressions that are "valid"? Should XPST0005 be narrowed down to only apply on kind tests? (if so, should probably apply both to steps and SequenceType scenarios)
We on purpose did not constrain it to specific expresssions. Best regards Michael
Consider this scenario: A user constructs nodes with element constructors, and then later on filters them with path expressions(indirectly, perhaps as part of other nodes). One implementation do this fine, but another one has decided to generate anonymous element types for the constructed nodes and therefore fail. What I find interesting about XQuery is that it's an XML-aware, statically-typed, "real" programming language. But I don't see where the XPST0005-mechanism fits in. It isn't a well-crafted typing feature, it is a free-card which says "Do whatever you like". If one knows what static error checking is about -- spec it. If not, what potential problems aren't you not missing then? XQuery 1.0 isn't the end of the world, but what you put in it you can't pull out, which can pose a problem to XQuery 1.Next. I'd rather see real static error features in XQuery 1.Next.
Frans, The XSLT and XML Query working groups had discussed you comment. The consensus was that the behavior you describe was the one intended. The extension mechanism obviously may interact with other parts of the specification, and each vendor can decide how best to deal with such potential issues. The XSLT and XML Query working groups have decided to close that bug with no further changes. Please let us know if you agree with that resolution. Best regards, - Jerome, on behalf of the XSLT and XML Query working groups