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

Re: XSLT and XQuery

• To: xml-dev@l...
• Subject: Re: XSLT and XQuery
• From: Mike Champion <mc@x...>
• Date: Tue, 08 Jan 2002 01:45:32 -0500
• In-reply-to: <005801c19807$fff31bc0$0301a8c0@n...>

1/8/2002 12:47:45 AM, "Jonathan Borden" <jborden@m...> wrote:

>What could possibly require _a year_ more work? specifics please.

I raised the issue because the W3C needs to respond to and manage the world's 
expectations for what to expect and when. I really don't know that much about
the specifics.  

Jonathan Robie, Michael Kay, Michael Rhys, Evan Lenz, and others have been 
discussing this for some time now in this and related threads.   
Two posts that describe some of the complexities are
http://lists.xml.org/archives/xml-dev/200201/msg00199.html
http://lists.xml.org/archives/xml-dev/200201/msg00207.html

I think it's basically:
- Unify the XSLT/XPath/XQuery data model.  This may be more or less done
- Make sure that queries can be defined to return schema-valid results
- Sort out/Respond to feedback on the latest draft, including
    Strong typing as a requirement in XQuery; is there enough gain for the pain?
    The use of quasi-XML syntax in the XQuery element/attribute constructors
    The XQueryX pure XML syntax -- is it needed? Should it be more XSLT-like?
    Updates - should they hold up the spec to put in updates.

So, XQuery -- as currently defined -- could easily take a year or more to sort out 
before they get to a Candidate Recommendation, especially if they add updates 
(as many are pleading). 

My personal understanding is that "make sure that queries can be defined to 
return schema-valid results" (aka strong typing) is the really central technical problem here. 
 They can't rush XPath 2 out until that is sorted out, because the type system is shared by 
XPath, XSLT, and XQuery.  Also, if XQuery is strongly typed, 
the update language should be as well, so it can't be rushed out either.

There's also a rather interesting political/psychological/economic/something problem 
that XSLT and XQuery end up sounding awfully similar.
Sorting that out internally and coming up with the right external story seems
 to be a work in progress.

So this is the "all this" I'm referring to, and I'm sure I've oversimplified.    

So, what is to be done?  Looking at recent history for inspiration ....
The DOM "punt on the hard problems each iteration" strategy is out, because the type system can't be retrofitted.
The XLink "tweak it until people have learned to live without it" outcome is one possibility I worry about. 
The Schema "if it's too complex new specs will emerge that fork the community" scenario is another possibility,
especially if XSLT is considered a "query language".  As with RELAX-NG, some see this as a Good Thing.
The XSLT "the business world can't wait for the Recommendation, so implement the draft" scenario may be the best we
can hope for, even though the draft could be a tar baby for the early adopters.  Is that more or less the
"extreme programming" scenario? 
  

• Follow-Ups:
  • Re: XSLT and XQuery
    • From: Soumitra Sengupta <soumitra@b...>

• References:
  • Re: XSLT and XQuery
    • From: "Jonathan Borden" <jborden@m...>

• Prev by Date: Re: XSLT and XQuery
• Next by Date: [ANN] New Breeze XML Binder Release
• Previous by thread: Re: XSLT and XQuery
• Next by thread: Re: XSLT and XQuery
• Index(es):
  • Date
  • Thread