[
Lists Home |
Date Index |
Thread Index
]
Uche
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.
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.
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...
Best regards
Michael
PS: I assume that you would choose the iterator's semantics to be
declarative and not procedural...
> -----Original Message-----
> From: Uche Ogbuji [mailto:Uche.Ogbuji@fourthought.com]
> Sent: Thursday, December 30, 2004 11:44 AM
> To: Daniela Florescu
> Cc: Alan Gutierrez; Kevin Jones; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Streaming XML (WAS: More on taming SAX (was
> Re:[xml-dev] ANN: Amara XML Toolkit 0.9.0))
>
> On Mon, 2004-12-27 at 13:31 -0800, Daniela Florescu wrote:
> > > I've gotten pretty good at assembling a SAX engine quickly by
> > > composing one using resuable strategies.
> >
> > Alan,
> >
> > you didn't answer my question. Besides the personal
> > interest and fun, where there any technical reasons why
> > Xquery/XSLT wouldn't have been the right choice ?
> >
> > Instead of writing Java over SAX, isn't it more convenient
> > to write:
> >
> > for $x in //foobar
> > where some:predicate($x)
> > return my:function($x)
>
> I'd rather write
>
> [ myfunction(x) for x in root.xpath('//foobar') if somepredicate(x) ]
>
> This works *as is* today in Amara toolkit, and is pretty efficient.
>
> So why would I (or you) expect the Python developer to have to learn
> some complex, entirely new programming language to achieve the same
> goal?
>
> > and leave the smart streaming strategies to implementors
> > to figure out ?
>
> There are smart strategists implementing systems other than XQuery,
you
> know.
>
> > Did you try XQuery/XSLT and fail ? If yes, where did they
> > fell short ?
>
> I'd rather ask you, where there areas where all the many native XML
> processing facilities failed for you, when you decided to develop
> XQuery?
>
> Python and Java came before XQuery, so I don't see why they have to be
> the ones to justify themselves.
>
>
> --
> 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
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
|
