Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Fri, 2004-12-31 at 00:09 -0800, Michael Rys wrote: First of all, let me thank you for this message. I suspect that if this subthread had stemmed from a message such as this, the result would have been much more even tempered. You are not coming in with a superciliously wonderment at how primitive developers could still be contemplating any language except for XQuery for XML processing (my interpretation of what got my ire up earlier in this thread). It's already clear that I don't like XQuery, but I'm happy to engage with you on these points to try to address the debate for developers who have no prejudices either way. > I have nothing against Python (and only little against Java :-)), but > one reason that you cannot just use any language that happens to have an > XPath() function is composability of the type system and language. > > If you extend your type system to include all the XSD types and XML node > types, and make the language composable with your XPath expressions, you > will end up either with a new language that is inspired by your > language, but for a new user will have similar complexity to learn as, > for example, XQuery (70% of which is part of XPath 2.0 as well), or a > mess. The only people that will have it simpler are the ones that > already know a bit about your original language. I do agree that if one wants to use XSD types, that it's hard to beat the likes of XPath 2.0 and XQuery. However, to touch on another permathread, many people do not like the superposition of strong *or* static typing on XML. I've written on it [1], we've all flamed out on it [too many threads to count] and we can probably agree to disagree on the usefulness and quality of WXS data types. In my processing I do not use WXS data types. I think there are many other developers who will never need to use WXS data types. I think that for such people, this advantage of XQuery and XPath 2.0 falls flat. And to go even further, for such people, this actually puts XQuery and XPath 2.0 at a disadvantage, because of the complexity it adds. As for core XML node types, I don't want to speak for Java, but Python has a lot of dynamic typing features that make it so natural to process XML node types that I don't think we miss much from the fact that this composition comes one level higher than the core Python data model. Aside: I think that someone could easily take advantage of Python's dynamicism to incorporate WXS data types, and that the result wouldn't bee as complex as you suggest, but I admit that I'm not interested in such a project. Eric van der Vlist started had down that path, but I suspect he's lost interest as well. > Since the W3C due to its make-up cannot decide to just use SQL, Python, > APL, C# or Java as its basis for the XML Query language, it decided to > build XQuery to provide the composability. > > If you decide that you want evolve Python or another language that way, > feel free to do so. The guys behind Xen and C-Omega are looking at this, > as are others (and there used to be a similar approach to embed SQL, for > some better examples, see Arthur Whitney's work). > > Once you have done that, you just created a new language that will > compete with XQuery/XSLT etc that may have some advantages in some > circumstances but will in the end be just another one. > > If OTOH, you are fine with the limited composability since it covers the > 80% use cases for you and the language is declarative (Java or C# > current iterators are not), then you are of course correct that the > syntax does not make much of a difference. This, I think, is where we meet. It is also a large part of the reason why XQuery will never drive out the many other ways of processing, nor should it. > But then I think Dana would agree. Note that the discussion was about > using low-level processing APIs and not calling an XPATH() processor > within a declarative iterator... Not really. I think that perhaps this was a point of confusion on her part (but that's just a guess). The XPath iterator example I posted was from Amara, discussion of which was the root of the thread. Amara provides tools for several different strategies of processing, and a subthread emerged discussing how Amara provides a tool for generating a SAX state machine from an XPath subset. This XPath-lite (we've been calling it XPattern) itself is a declarative device that can be used in any other implementation, and others who had implemented or contemplated the same thing began a discussion of how to perhaps standardize this XPattern. So in fact we *were* essentially talking about using XPath in a declarative iterator. The nuance in our case was that we were also discussing the semantics of the iterator (in terms of SAX events). But this is no more a scorning of declarativity than it would to have on an XQuery implementor's list a discussion of implementation strategies for FLWOR expressions. > PS: I assume that you would choose the iterator's semantics to be > declarative and not procedural... Yes, although another side-thread I got [expletive deleted] into seems to show that many consider it a violation of SAX's basic nature to define it in any terms other than a procedural execution model. Perhaps I'm a bit too imaginative, I must say that such a limitation would tend to make me agree with you and Florescu at least to the extent that SAX is not an appropriate basis for specifying this XPattern we're discussing. I agree that it should be a declarative basis (and never would have meant to imply otherwise). [1] http://www.adtmag.com/article.asp?id=6965 Happy New Year. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Use CSS to display XML - http://www.ibm.com/developerworks/edu/x-dw-x-xmlcss-i.html Full XML Indexes with Gnosis - http://www.xml.com/pub/a/2004/12/08/py-xml.html Be humble, not imperial (in design) - http://www.adtmag.com/article.asp?id=10286 UBL 1.0 - http://www-106.ibm.com/developerworks/xml/library/x-think28.html Use Universal Feed Parser to tame RSS - http://www.ibm.com/developerworks/xml/library/x-tipufp.html Default and error handling in XSLT lookup tables - http://www.ibm.com/developerworks/xml/library/x-tiplook.html A survey of XML standards - http://www-106.ibm.com/developerworks/xml/library/x-stand4/ The State of Python-XML in 2004 - http://www.xml.com/pub/a/2004/10/13/py-xml.html
|
