This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
err:XPST0005 is defined in XQuery as 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(). Consider the expression: if (...) then () else fn:error('err:MyError') The static type of this expression is empty-sequence(), which is the union of 'none' and 'empty-sequence()', as noted in paragraph 2 of http://www.w3.org/TR/xquery-semantics/#sec_content_models According to the definition of XPST0005, this should raise XPST0005 at static type checking, rather than possibly calling fn:error at run time. A suitably constructed typeswitch could also exhibit this behaviour. Is this intentional? A glance at the XQuery Update Facility shows that this is a problem here too, as the updating operations have static type empty-sequence(). I note that this error is only ever tested in XQTS when a step in a path expression is found to be empty-sequence() (a case specifically mentioned in the XQuery specification). Other than the cases mentioned above, I think it may also be thrown during static type checking of 'for', 'for/at', 'let', variable references and function calls. Since implementations are allowed to use static type checking extensions (which might infer a static type of empty-sequence() when the standard rules cannot), testing of this error code could be quite tricky.
Should (expr) treat as empty-sequence() raise XPST0005 for some expression 'expr'?
I see what you are saying. I think the err:XPST00005 makes sense to catch invalid xpath step. Otherwise, it is not useful.
Another problem with it is that it makes the XQuery Formal Semantics very fragile. e.g. consider the static typing rule for fs:item-sequence-to-node-sequence statEnv |- Type <: attribute*, (element|document|text|processing-instruction|comment|xs:string| xs:float| ...|xs:NOTATION)* --------------------------------------------------------------------------- statEnv |- (FS-URI,"item-sequence-to-node-sequence") (Type) : attribute*, (element|text|processing-instruction|comment)* Imagine we were to add a specialization of this rule for the case where Type is empty-sequence(). The corresponding return type would be empty-sequence(). Introduce such a rule and suddenly XPST00005 is thrown when you create an empty element, e.g. <foo />.
I think this rule is very arbitrary and unfortunate. It breaks compositionality - if two expressions have the same static and dynamic semantics then it should be possible to use them interchangeably. A much better rule would be: it is a static error if the static type of the expression on the rhs of the "/" operator is empty-sequence(). And there might be a few other contexts where one wants to apply the same rule, e.g. to the expression in a predicate, the expression in an order by clause, etc.
Actually, the problem I see Tim report is that none is inferred for error() instead of an error type that could be preserved. Note that in almost all cases, non-error() containing expressions that statically yield empty-sequence() are because of a programmer's mistake and this raising the error is good in all of these cases. While the biggest use-case is path expressions, there are many other places as Mike notes. Also note that changing this rule as an errata is not acceptable, since it impacts existing implementations.
I agree with Mike. I think that XPST00005 error is the sort of thing a compiler might warn a user about during compilation rather than it actually being a fatal error. I find it particularly annoying that it means that the behaviour changes depending on whether or not static typing is switched on. I also agree with Michael regarding the type of fn:error. I rather like the way Haskell approaches exceptions in a functional language. I've found there's rather a lot to be learned from Haskell, particularly with regard to handling side-effects in a functional setting. Without breaking existing implementations, might a change be made which states that an implementation may raise XPST00005 but is not required to do so?
I believe it's already roughly possible for an implementation to not raise the err:XPST0005 error - it's called not implementing "XQuery Static Typing", and it's what a large number of XQuery implementations already do. Of course, they still implement static typing, but they follow the much more useful optimistic typing semantics.
most implementation implements optimistic static typing. Also XPST0005 is really used to catch invalid step expression during path expression analysis instead of raising errors for empty sequence expression.
Of course, because most implementations don't implement this part of the specification doesn't mean that this isn't a problem with the specification. "Also XPST0005 is really used to catch invalid step expression during path expression analysis" That may be the intention of the specification but it isn't actually what the specification seems to say.
Tim, The Query Working Group considered this bug report on 15 April 2008. It was the consensus of the working group that, if we were starting over to design XQuery from scratch, we might find a better definition for error XPST0005, but the current definition does not constitute an error that needs to be corrected by an erratum. In general, the design for static typing in XQuery 1.0 is quite pessimistic, and this error code represents one case in which static typing rules might be loosened in a future version of the language. If you are satisfied with this resolution of the issue, please mark this bug report as "Closed." Thanks, --Don Chamberlin (for the Query Working Group)
Could you please give a bit of background as to the reason for this decision? I was hoping that your decision would be to limit XPST0005 to steps in a path expression. Am I right in thinking that all XQuery Update expressions type as empty-sequence, and therefore must raise XPST0005 if static typing is enalbed? Do you know whether other implementations (which support static typing) raise this error as per the specification?
(In reply to comment #11) > Could you please give a bit of background as to the reason for this decision? > I was hoping that your decision would be to limit XPST0005 to steps in a path > expression. > Am I right in thinking that all XQuery Update expressions type as > empty-sequence, and therefore must raise XPST0005 if static typing is enalbed? > Do you know whether other implementations (which support static typing) raise > this error as per the specification? SQL Server 2005/2008 is implementing pessimistic static typing, however, we do not error out on if (/a) then () else () (we are not supporting fn:error). We often raise static errors on other expressions than path expressions that can lead to always empty results, but raise more specific errors (e.g., () + 5 will raise a static error).
I agree with Tim, other than raising errors for invalid xpath steps, this error has no other significance. Many xquery implementations choose to ignore this other than raising errors for invalid xpath steps.