Re: Why not reinvent the wheel?

["Thomas B. Passin" <tpassin@home.com>]

Charles Reitzel"  wrote the latest in this spat:

> But do you see the cognitive dissonace some of us are experiencing here?  If
> such a mapping is possible, then you have just proved that the processing
> requirements for the XQuery subset are the same.
>
>
> >Clearly, an equivalent XSLT stylesheet can
> >be one way of representing an XML Query, but it will be
> >semantically different from the original XQuery because
> >of differences between the two languages.
>
> Without getting into semiotics - please - I don't get this one.  If both
> will return the same result set against all given data sets, then they have
> de facto the same semantics.  The same can be said for equivalent but
> different XSLT stylesheets or XML Queries.  If they aren't semantically
> equivalent, then the XSLT representation of the original XQuery was
inaccurate.
>
> If you meant something else by semantically equivalent, I submit that "same
> input produces same output" is the most useful definition of semantic
> equivalence in software engineering.
>

Come on, guys, we need a usable query language, and it has to support inserts
and updates as well as retrieval.  We're using trees, so it has to have  tree
navigation and selection machinery,

Now, these two queries produce the same result from their intended targets:

1)
select person,number from phonelist

2)
<template match='/phonelist'>
<xsl:for-each select='person'>
    <xsl:value-of select='.'/>
    <xsl:value-of select='../number'/>
</xsl:for-each>

That doesn't mean that xslt is semanticaly equivalent to xslt.  I'm sure many
sql queries could be written by algorithmically transfoming some xslt
statement and vice-versa.  It still doesn't make them the same.  (I know,
there are a lot of other types of queries that aren't congruent.  But I'm
ignoring that to make this point).

For that matter, you could probably do all xslt tasks using java or DSSL, but
that doesn't make them equivalent.

Personally, I would much rather write 1) than 2) for this little task.   And
it's easier to debug and more likely to produce the results I expect.

Remember too that many DOM trees are build using SAX parsers.  That doesn't
mean that SAX as a competitor to DOM, should have been avoided.  It
illustrates there can be several different solutions each of which is better
in different circumstances.

I do agree that if xslt takes a subset of xpath and then extends it one way
while xql takes a different subset and extends it in incompatible ways, we
would have an undesirable situation, because you'd need to develop different
code for all three (both for authors and developers).

This argues for getting the right set of things into XPath, to minimize this
problem.  It looks like the working groups are trying to accomplish this.

So I say, I want a query language that is intended for queries, that is
compact and readable,  that can produce node-sets (and possibly xml and text
output), and that can be used for updates and inserts.  Path navigation should
be as familiar to me as possible, and if it's essentially xpath that's all the
better.

It sounds to me that this is happening, and I have no complaints - except I
want it today!

Cheers,

Tom P