XQJ (JSR 225)

[Brian Maso]

As someone who was there at the discussions(long ago), I can confirm that
the DB companies kept a pretty tight focus on XQuery as a DB query language
and the transformation use-case was pretty much ignored. There was a strong
bias towards keeping the API as JDBC-ish as possible by IBM and Oracle.

IIRC, Per Bothner was the strongest advocate within the EG of making the API
more amenable to the XQuery use-case. Since the XQJ committee was pretty
dominated by large DB companies, who really felt this was not an important
use-case, his efforts were not received enthusiastically. The thinking was
that, if the initially-proposed JDBC-like API was modified very much, then
no DB company would have the resources to change their experiemental
implementations, and certainly the test compatibility kit (TCK) could not be
made in a reasonable amount of time.

Independent voices (like Per's) really didn't have enough votes and couldn't
overcome the economics of the situation to influence the API very much from
its JDBC-esque bias. I kind of lost interest in committing time to the EG
when I realized the big DB vendors were just going to do what they wanted,
and that many real-world XQuery use-cases were not going to be served very
well by the API.

I figured someone would develop a simplified library over top of XQJ to
support the transformation use case when it was eventually released --
though I never thought it would go until 2009!

Best regards,
Brian Maso

On Thu, Jun 25, 2009 at 8:03 AM, Michael Kay <http://x-query.com/mailman/listinfo/talk> wrote:

>  Yes, I think you're right.
>
> XQJ has a strong "client server" feel to it, with its strong notion of a
> connection between the application and the database, and a "data source"
> that you connect to. It's treating XQuery as a database query language whose
> typical usage is in a classic 1980s-style connection-oriented client-server
> database environment. To what extent this justifies some of the peculiar
> design decisions, for example the way that results are delivered, I find
> hard to judge - I suspect that better abstractions could have been found
> without sacrificing performance in the client-server environment. For
> example, I can't see any reason why a standard Iterator couldn't have been
> used in place of the XQForwardSequence, and I see no justification for the
> restriction that you're only allowed to look at each returned item once
> before it vanishes into thin air. A lot of the implementation effort and
> performance overhead is caused by the requirement to enforce such arbitrary
> rules: I hate it when as an implementor I'm required to do work that makes
> the user's life more difficult.
>
> There are certainly plenty of people who see XQuery being useful in roles
> other than a client-server database query language. It's possible to use XQJ
> in such environments, but it doesn't feel very natural, and may be
> inefficient.
>
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>  ------------------------------
> *From:* David A. Lee [mailto:http://x-query.com/mailman/listinfo/talk]
> *Sent:* 25 June 2009 15:36
> *To:* Michael Kay
> *Cc:* http://x-query.com/mailman/listinfo/talk; http://x-query.com/mailman/listinfo/talk
> *Subject:* Re:  XQJ (JSR 225)
>
> I don't want to speak for others, but I find this a curious discussion.
> My opinion, from a definite 'outsider' trying to ignorantly catch up on all
> these technologies,
> is that there seems to be a schism of philosophy regarding XQuery.  I see
> it as sorta a "world view" thing, so I shall use that phrase.  This is
> alluded to in Mike's (co-authored) excellent book "XQuery from the
> Experts".    My naive view of this is that it seems there are some groups of
> people who view XQuery as really a "Database query language" and other
> people who view XQuery as a "XML Transformation language".   This world view
> seems to affect a whole bunch of things, from the language syntax and design
> itself, to API's to users discussing "what language is 'best' for XYZ".
> Even the name "XQuery" itself leads to fundamental, often unconscious
> assumptions around this world view that affect how it is used.
>
> I could definitely imagine that the XQJ authors (although I wasn't there so
> I'm guessing ...) may not be so  much ignorant of alternative API models,
> but rather drive decisions from a world-view of "What is XQuery".   That can
> (and does) lead one to consider some models and reject others almost
> off-hand.
> The same thing is seen in all sorts of other fields-of-thought (such as the
> sciences, physics, engineering, biology etc).
>
> IMHO, this 'schism of world views' around XQuery is both good and bad.  Its
> good because it can attract people from different backgrounds to consider
> XQuery where they otherwise wouldn't, and to think of it in terms of their
> experience.   Its bad because it has the opposite effect as well, it
> discourages people from considering XQuery as anything other then their
> experience and imposes preconceptions, often unconscious.
>
>
>
> David A. http://x-query.com/mailman/listinfo/talk  http://www.calldei.comhttp://www.xmlsh.org
> 812-482-5224
>
>
>
> Michael Kay wrote:
>
>   I wonder why the design was not based on the JAXP API for
> XSLT rather than on JDBC...
>
>
> Largely NIH syndrome (not-invented-here). It's true JAXP has major faults
> too, but that's no excuse for ignoring its good points. I suspect the XQJ
> designers had never used JAXP in anger - no-one is familiar with all
> possible precedents, after all.
>
> Regards,
>
> Michael Kayhttp://www.saxonica.com/http://twitter.com/michaelhkay
>
> http://x-query.com/mailman/listinfo/talk://x-query.com/mailman/listinfo/talk
>
>
> _______________________________________________
> http://x-query.com/mailman/listinfo/talk
> http://x-query.com/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20090625/62dcae29/attachment.htm