RE: () equivalent to () ?

> You mean that the static type of "()" is void(), while for 
> "data()" it is 
> "xdt:anyAtomicType()*"? Could you elaborate? What impact in 
> practice does 
> this difference in static types, whatever it is, have? 

It probably affects XQuery more than XPath or XSLT: in an XQuery
implementation that does the full (pessimistic) static typing, an expression
such as [data(()) | *] is going to fail statically, because the operands of
"|" have to be sequences of nodes.

But XPath and XSLT are also allowed to do early type checking, and Saxon for
example will give you a warning on this expression, or at least, on others
that are very similar. For example if you declare

<xsl:variable name="d" select="data(*)"/>
<xsl:value-of select="$d | *"/>

you'll get a compile-time warning that the expression can succeed only in
the special case where $d is an empty sequence.

The typing of empty sequences is a pretty esoteric subject, full of traps
for the unwary. A system that does static typing (even the optimistic kind)
can distinguish (treat differently) an "empty sequence of integers" and an
"empty sequence of strings", but to a system without static typing they are
indistinguishable.


Michael Kay
http://www.saxonica.com/

> 
> >
> > > However, testing this theory in practice in a host language
> > > such as XSLT 2.0
> > > is impossible(?) since all comparison operators returns the
> > > empty sequence
> > > when an operand is the empty sequence.
> >
> > You're talking about a new comparison operation of your own 
> invention which
> > you haven't fully defined, and which seems to differ 
> slightly from those
> > already defined in the language. You're welcome to do this. 
> First you need
> > to define what you want its semantics to be, and then you 
> can implement it
> > as a function. But so far, you haven't defined its 
> semantics except by
> > appeal to "common principles" - which you will quickly find 
> are not as
> > common as you thought.
> 
> Right, the question was ill prepared and badly put, there's 
> not much more to 
> say.
> 
> 
> Cheers,
> 
> 		Frans