RE: Want to process XHTML in my XSL stylesheets.

> Mike Kay wrote
> > but my suspicion is that in most cases the
> > only type you can deduce for the result tree is "document".
> 
> I strongly agree (and just said the same to Jonathan Robie on 
> XML-dev) but given that, is there any point in having XPath2 
> weighed down with all this static typing machinery?

I think there are potential benefits in having static typing rules in
XPath 2.0. The ability to deduce the type of the final result tree is
not one of them. (I know lots of good programming languages that do
static typing, but I don't know any that use it to prove theorems about
the output of the program.) 

I certainly believe that the way static typing is defined in the working
drafts is not yet right (it doesn't achieve the stated aims), and it's
not worth implementing in its current form. I haven't given up hope,
though I do think that the dynamic typing rules are much more important.


I would rather like to be able to reject

<xsl:variable name="x" select="'title'"/>
<xsl:value-of select="$chap/$x"/>

as a static error, on the grounds that the rhs of "/" must be a
node-sequence not a string. That's the kind of simple benefit I expect
from static typing. Unfortunately if someone writes:

<xsl:variable name="x">title</xsl:variable>
<xsl:value-of select="$chap/$x"/>

then no amount of static typing helps, because the expression is
perfectly valid in XPath 2.0: it just doesn't do what the user expected
(it outputs "title").

So my view is that some static typing in the language can be handy, but
we shouldn't expect it to work miracles, and if it gets too much in the
way, we're better off without it. 

The static analysis that a processor does for optimization doesn't
actually need to be standardized, but it becomes a lot easier if the
language imposes some clear rules. An expression like "//item[@x =
$param]" becomes a lot easier to handle if you know in advance whether
$param is going to be an integer, a string, or a date.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list