Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Why not reinvent the wheel?
 At 09:51 PM 2/22/2001 -0500, Charles Reitzel wrote: >One objection is that us poor developers can only squeeze so many syntaxes >into our heads (at one time anyway). Subtle differences in processing will >only cause grief when debugging complex programs. They both have >if-then-else and for loops. For better or worse, they are both programming >languages - and similar ones at that. Better to get it right once. And then he wrote: > Yes, it is a bit easier to read the FORTRAN-like syntax. If syntax sugar is > the compelling argument here, why not develop an XSLT generator? I am > encouraged by coordination around XPath 2.0. Why not go the rest of the > way: just make XSLT the XML syntax for XML Query? Given the second quote, I assume that Charles agrees that it is easier to read and write XQuery (which has variously been called XSLT-like, Java-like, FORTRAN-like, and SQL-like!). There probably *will* be XSLT generators for XQuery. It may make sense to have a group of people get together and define a mapping from XQuery to XSLT. The mapping in the other direction probably makes less sense. XSLT has a number of constructs, such as templates and match patterns, that do not map directly onto anything in XQuery, and I do not see a need for them in XQuery. We are trying to keep XQuery as small as we can while still meeting our requirements. There is hefty debate about just exactly what the XML syntax for XML Query should do. Should it be a syntax for humans to author XQuery in? Should it represent the abstract syntax parse tree? Should it be a representation of the XML Query Algebra representation of a query? Since XML is just a way of representing information, I don't think that there has to be one and only one answer to this question. 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. >Second, we are not talking about a commercial product, but a standards >process. This fragmentation in the standards space will dilute commercial >support so that it will take longer before we get decent implementations of >any query language. Competing standards actually delay or prevent >competition among products. Ask any Unix vendor. Ask Microsoft. Too many >standards also weeds out small players. Only the big boys can support >them all. I'm confused. You seem to be suggesting that we should not develop both XQuery and XSLT because we might not get decent implementations of either. I thought there were already quite a few implementations of XSLT, and that certainly includes some good ones. It is quite easy to embed these in your web environment. What exactly are your fears with regard to XSLT support? As for XQuery support, if nobody decided to implement the language, it would die, and our discussion on this list would be moot. I am encouraged by the fact that several universities and companies are already working on XQuery implementations, and I have seen several demos of prototypes. Arnaud Saquehet's implementation is fairly complete, though not completely compatible, and it is open source: http://db.cis.upenn.edu/Kweelt/ I can't name names because I don't know exactly who is saying what in public. But I'm quite confident that XQuery will be implemented. Also, would you say that the W3C should not have supported both CSS and XSL? What differences do you see between that situation and this one? I think it is a given that some people will never see a reason for XQuery, since XSLT exists. There is a sizable community of people who do see a reason for XQuery. I remember when people were really confused about why XSLT was needed. I remember long discussions in the SGML community about whether there was a need for XML. Object orientation was invented in 1967, but object orientation was not mainstream until the late 1980s. New technologies take time to understand and appreciate. Of course, hogwash takes time to recognize and discard. >Jonathan Robie keeps saying that the XML Query use cases are different than >XSLT. But there have been numerous protests to the contrary on this list. >Perhaps he could tell us which of the XML Query use cases cannot be applied >to XSLT? I never said "cannot be applied". Since XSLT is Turing complete, it would be wrong to say that the use cases cannot be applied to XSLT. It is just a lot harder to do so. In fact, quite experienced XSLT programmers have sent me wrong solutions to some of the use cases, and we've had long discussions before we could agree that the proposed solution was wrong. Take a look at Evan's paper. Even some of his examples show things that I find significantly less straightforward in XSLT. You say that there have been protests on this list, and therefore I should work up a list of the use cases that cannot be applied and defined it here. My obvious worry is that this would be an infinite time swamp. Nobody has yet provided a complete set of solutions to the use cases in XSLT. Several people have started. Evan has solved a few for which I had not previously seen solutions. I would be very interested in seeing a complete set of use cases, but I'm not willing to spend the time to create them. >I am not buying the optimization argument either. By exposing random access >XPath (pointed out by Joe English), there is effectively no difference >between them. Random access XPath? I think that Joe English pointed out that we allow the parent operator in XPath. I think that's a long ways from saying there is no difference between XSLT and XQuery for query optimization. >My personal opinion, is that a standard schema would provide >a stable footing that allows work to go ahead on static analysis of document >bases. This document analysis will drive query optimization (as pointed out >by others on the list). Ordering and equality rules for datatypes will >assist this effort! This is all true, assuming you mean "a common approach" when you say "a standard schema". The XPath 2.0 effort goes beyond sharing syntax. Both XSL and XML Query would benefit by good static analysis of document bases. Jonathan These are my opinions right now. They may be quite different from the opinions of Software AG, the W3C XML Query Working Group, or the opinions that I will have after reading and considering your response. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
