Re: Why not reinventing the wheel ?

[David Rosenborg <david.rosenborg@pantor.com>]

Hi Eric,

> I enjoy XSLT a lot, but if some brilliant guys think they can define a
> language that is better fitted for some purposes why should I worry
> --even if there is a huge overlap ?

If you just make the definition of your universe at hand sufficiently narrow, anyone
can claim that their particular solution is the best for the job. If every
working group at W3C used this method to justify new syntaxes, however brillant
they would be, it would soon get very messy.

I think that there's definitely a need for XQuery, however, it's problem domain is not peculiar
enough to justify a completely new syntax. And I don't think this marketing plot with
case-insensitive keywords is enough to make the SQL-people come running into the XML world.
 
> Some competition between may be a good motivation and I would rather
> regret that XSLT has been lacking credible competitors and alternatives
> for such a long time.
>
> I see competition as simulating and source of diversity and richness (if
> it's true for schemas, why not for XSLT? ).
> 

If XSLT/XPath and XQuery were developed by competeting companies, or even if one was under W3C
and the other under ISO, this would have been a natural thing. And I agree that some competition can be fruitful.
However, I'd like to think that *consistency* is an important issue for W3C. Do you mean this is not of importance
in this case? 

> If people had not always being trying to reinvent the wheel our cars
> would roll on logs...

I think looking for new, unifying and better syntaxes is important, but I think it should be done as a separate
effort.

Also, a new and brilliant syntax doesn't have to be incompatible with the old one. It would have been much
better if XQuery had taken an evolutionary path rather than restarting from scratch. My criticism 
is partial here though, since much has been borrowed from XPath which is good.
By evolutionary I mean this: XSLT and XQuery share a common pattern:

1) select nodes
2) generate the result tree

In XSLT the first is handled by XPath and the second by template instructions. An evolutionary approach
had been to extend, and subset (for optimization purposes) each of these to get a comprehensive and yet
optimizable solution. As I said, XQuery does do this with XPath (modulo namespace handling and case-insensitive keywords),
but for the generative part nothing is reused. Strange.
About terseness: building XQuery on XSLT/XPath doesn't necessarily require you to specify a full stylesheet for each
query. Just as there are simplified constructs in both XSLT and XPath there could be in XQuery:

A simple query could be just

<xquery select="a"/>

If you needed to order the result, bring in some more power,

<xsl:for-each select="person" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:sort select="name"/>
  <xsl:copy-of select="."/>
</xsl:for-each>

And so on.

Well, let's hope all this gets settled down in the XML mapping :-)

Cheers,

</David>