Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Why not reinvent the wheel?
 At 11:28 AM 2/24/01 -0500, Jonathan Robie wrote: >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. I appreciate your open-mindedness. You've also been a good sport about taking the heat for XQuery. 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. >On 09:51 PM 2/22/2001 -0500, Charles Reitzel wrote: >>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? You understand correctly. There are throughput and latency issues that limit the scalability of current XSLT implementations. We share this concern, I believe. I just don't think XQuery, per se, contributes much to the solution. It may even detract from it. >I am encouraged by the fact that several >universities and companies are already working >on XQuery implementations... I appreciate that such implementations must be gratifying to everyone who has worked hard on the XQuery spec. Time will tell which ones mature to be deployed in large scale, production environments. >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? That is a somewhat different case. I think the XQuery group would do well to emulate the roadmap laid out for the transition from CSS to XSLT. This whole discussion started when Simon StL put out a call for just such a roadmap for the growing family of XML specs. >>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". Should not be applied, then. >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. I have read Evan's paper. I'll read it again, but I'd like to hear from you (or any other XQuery protagonists out there): for which XQuery use cases is XSLT an inappropriate tool? No big time sink, I hope. Just give us a list of numbers from http://www.w3.org/TR/xmlquery-use-cases, and I'll go read those again, too. >>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. Yup, I'm thinking at the basic, algorithmic level. I think we basically agree on this. I might go further, in that I think this is where the big gains will be found. take it easy, Charles Reitzel 
|
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
|
|||||||||
