W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2007

[Bug 4273] [FS] data on element()

From: <bugzilla@wiggum.w3.org>
Date: Mon, 05 Nov 2007 22:32:25 +0000
To: public-qt-comments@w3.org
Message-Id: <E1IpAUb-0004oe-8g@wiggum.w3.org>


------- 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)
    "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
Received on Monday, 5 November 2007 22:32:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:21 UTC