OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: XQuery -- Reinventing the Wheel?



Michael Rys wrote:
> Now I do not disagree that there is a subset of XSLT that should have the
> same semantics as XQuery, but I consider defining a subset of XSLT instead
> of XQuery to be a very dangerous proposition. Once you start subsetting an
> existing language that way, you may lose composability (how do
> you make XSLT
> composable without the template-rule? Chaining XSLT-files? Give me a
> break...) and end up with a very messy syntax. And this assumes that you
> "fix" some of the current messy semantics of XPath.

I don't follow your link between composability and template rules...

Regarding composability, it's true that this is currently a semantic
difference between XSLT and XQuery. However, XSLT 1.1 will already be
changing this. By implicitly accessing result tree fragments as node-sets,
XSLT 1.1 provides a similar "subquery" mechanism as used in the expression
below (from the XML Query Algebra):

for b in (for a in bib1 do a/book) do b/author
= for a in bib1 do (for b in a/book do b/author)

The equivalent XSLT 1.0 formulation of the right-hand side of this equation
is trivial:

<xsl:for-each select="$bib1">
  <xsl:for-each select="book">
    <xsl:copy-of select="author"/>
  </xsl:for-each>
</xsl:for-each>

The left-hand side currently cannot be expressed by XSLT (without an
extension function). However, with the move toward composability effected by
the access to arbitrarily constructed trees as node-sets, XSLT 1.1, to say
nothing of XSLT 2.0, will be able to express this as follows:

<xsl:variable name="temp">
  <xsl:for-each select="$bib1">
    <xsl:copy-of select="book"/>
  </xsl:for-each>
</xsl:variable>

<xsl:for-each select="$temp/node()">
  <xsl:copy-of select="author"/>
</xsl:for-each>


My intention here is to identify converging semantics, not syntax. What I'm
wondering is why the models do not converge, when the gap between them seems
to be narrowing further and further (per the XPath 2.0 and XSLT 2.0
requirements docs, especially wrt typing). Maybe the gap *will* close; I
just don't get the impression that that is a goal of the Query WG. XML Query
and XSLT seem to have the same requirements in this area (or at least
proposed requirements). My question is: if the requirements do not differ,
why should the standards differ (apart from having multiple syntaxes)?

Evan Lenz
XYZFind Corp.