[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why not reinvent the wheel?
- From: Charles Reitzel <email@example.com>
- To: Vasileios Papadimos <firstname.lastname@example.org>
- Date: Mon, 26 Feb 2001 22:13:31 -0500 (EST)
At 10:10 AM 2/26/01 -0800, Vasileios Papadimos wrote:
>On Mon, Feb 26, 2001 at 12:10:43AM -0500, Charles Reitzel wrote:
>> 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.
>Just because you can rewrite an XQuery query into XSLT,
>with the same input/output, doesn't mean that you should
>necessarily do so, nor that XQuery is superfluous.
>We still have tens, or even hundrends, of programming languages,
>even though all of them are Turing complete!
Just because you can, doesn't mean you should. As a standards body, the W3C
should exercise restraint in foisting redundant standards on the web
>One of the reasons that relational databases have been so
>successful, is that they provided a better, succinct way
>to *express* queries. It's not that you can't express a >relational query
in a hierarchical or networked model;
>the relational, declarative query is simply easier to
>write, easier to understand, and easier to optimize.
>I believe the same is true for XQuery; having a simple,
>succinct way to form queries in a declarative way, and
>letting the optimizer decide on the best implementation
>is the way to go.
Yes, separation of query expression from execution plan and physical schema
is a good thing. You get it with both XQuery and XSLT for the same reasons
in each case. For both, the XQuery/XSLT engine will decide the details of
document traversal, intermediate tree building, sorting, etc.
That leaves the syntax issue, which IMO, does not justify an entire,
freestanding query standard. It may well justify a non-XML front end to
XSLT, however. I'm sure, day-to-day, I'd prefer to use one.
I think this would be a good evolutionary strategy. If XQuery is a front
end to XSLT, there is nothing stopping the intermediate format from being
optimized away, so to speak. But the underlying engine is the same.
Anybody remember cfront?
take it easy,