[
Lists Home |
Date Index |
Thread Index
]
> > > Also, I've never understood why the descendant axis is
> > supposedly easier to
> > > statically type than the ancestor axis.
> >
> > Because the child axis is easier to statically type that the
> > parent axis.
> > The type of an element (in the XDuce/XQuery sense) tells you
> > the possible
> > attributes and children but doesn't tell you the possible
> > parents.
>
> Well, there are two possible scenarios. In a closed world, we know all the
> types, in which case the type of the parent is the union of all types that
> have "this" as a possible child or attribute. In an open world, we don't
> know all the types, so the type of the parent is "any element or document
> node". The only difficulty I can see is that of deciding whether the world
> should be open or closed.
The closed world view isn't going to work in XSLT 2.0 (or XSLT 1.0 +
node-set) or XQuery because you can construct elements that may have
different types from those in your input document.
The two possibilities you mention are not the only two possibilities.
Imagine you have a schema
<!ELEMENT book (chapter+, appendix*)>
<!ELEMENT chapter (section+)>
<!ELEMENT appendix (section+)>
and imagine the following
<xsl:template match="chapter">
<xsl:for-each select="section">
<xsl:variable name="x" select=".."/>
</xsl:for-each>
</xsl:match>
Your closed world view would infer a type of chapter|appendix for $x, but
clearly in this case it is possible to infer automatically that $x is a
chapter. However, as far as I know, the XDuce and XQuery type systems
cannot do this: they can only infer that $x is any element or the document
node.
> In any case, as a user, I'd much rather have a weakly-typed parent axis
than
> no parent axis at all.
>
> I want to find all <section> elements whose depth in the tree is less than
> 4:
> //section[count(ancestor::* < 3)]
>
> You're not going to let me write that because you don't know how to
> type-check it? Gee thanks, I'll stick with XPath.
The problem arises when you try to use the result of a weakly typed
operation in a strongly typed context. Suppose in the above example,
instead of the xsl:variable instruction, you have something like
<xsl:value-of select="foo(..)"/>
and suppose foo is a function declared to have take an argument of type
"chapter". The XQuery type system, as far as I understand it, would reject
that with a static type error, and would require that the user explicitly to
cast the ".." to be of type chapter. This is obviously not a very
satisfactory situation. The more a static type system complains about
things that are actually perfectly OK and requires the user to insert casts,
the less useful it is.
James
|
