[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Why not reinvent the wheel?

  • From: Charles Reitzel <creitzel@m...>
  • To: Vasileios Papadimos <vpapad@c...>
  • Date: Mon, 26 Feb 2001 22:13:31 -0500 (EST)

wheel mean
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
development community.

>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,
Charles Reitzel



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.