[
Lists Home |
Date Index |
Thread Index
]
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 sucked 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
|
