- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 05 Nov 2007 22:32:25 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4273 ------- Comment #22 from jmdyck@ibiblio.org 2007-11-05 22:32 ------- (In reply to comment #21) > That makes sense. > > So the static type of fn:data(complex type of element-only) = > empty-sequence(), but applying fn:data() a value of such a type > would raise a dynamic error. It depends on what you mean by "a value of such a type" -- "a value whose type annotation is such a type" (in which case, yes, an error) or "a value matched by an element type whose type reference is such a type" (in which case, not necessarily an error). As I understand it, some ct(element-only) can derive ct(empty). Therefore, some element type whose type reference is a ct(element-only) matches an element node whose type annotation is a ct(empty). We know from the XDM spec that the latter has a typed-value (and thus an fn:data() result) of the empty sequence, therefore 'data on' applied to the former (if it yields a type) must be a supertype of 'empty'. I think the only other dynamic possibility is an error, so if it's a dynamic error, then the static type might as well be just 'empty'. > Would that require a change in the definition of error XPST0005? > > err:XPST0005 > 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(). I suspect that would stay as is. > Recalling that optimizations are allowed to avoid errors, I'm a bit concerned > that statically typing a call to fn:data() might introduce some strange > behaviour. e.g. An optimizer might use the identity: > > count( $seq ) = 0 when $seq has type empty-sequence() > > Is this a valid concern? If the expression $seq has the static type 'empty', then it's a static error according to the rule quoted above. Are you suggesting that an implementation might rewrite "count($seq)" as "0", thereby avoiding the static error? If so, note that the proposed text in Bug 4446 Comment #1 says "Expressions must not be rewritten in such a way as to create or remove static errors."
Received on Monday, 5 November 2007 22:32:32 UTC