XQJ (JSR 225)

[Michael Kay]

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. Lee

http://x-query.com/mailman/listinfo/talk  

http://www.calldei.com

http://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 Kay

http://www.saxonica.com/

http://twitter.com/michaelhkay 



_______________________________________________

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/049ab581/attachment.htm