[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Early Draft Review: XQuery for Java (JSR 225)

• To: <xml-dev@l...>
• Subject: Re: Early Draft Review: XQuery for Java (JSR 225)
• From: "Ken North" <kennorth@s...>
• Date: Thu, 1 Jul 2004 14:21:39 -0700
• References: <Pine.LNX.4.44L0.0406302252450.15133-100000@s...> <002b01c45f20$18c23730$1601a8c0@DURANTE> <40E41A21.6040708@e...>

Burak Emir wrote:
> An API for HTTP Posts means dealing with wires.
>
> An XQuery is an expression in a domain specific language - there might
> not even be a wire involved.

It's true there may be no wire involved for every XQuery application. But if an
XQuery engine is embedded in a standalone Java program, a developer might choose
to use streams, consumer/producer classes, or reader/writer classes instead of
using the XQJ API.

The overhead for XQJ-style programming (drivers, connection pooling, registering
data sources with JNDI, maintaining state, caching) is necessary for
distributed, multi-user computing. Why would you incur that overhead if you are
deploying in a single-computer environment?

> A developer might choose to write his own "engine" which makes up random data
or is a wrapper around an SQL client. He will have a hard time if
> he has to deal with strings.

If you look at the Java API for some of the existing XQuery implementations
(Galax, IPSI-XQ), they don't seem to have a problem dealing with query strings:
http://www.sqlsummit.com/XQueryProv.htm

> That is all I'm saying, but a tree alternative must be completely
> interchangeable with strings - this can make the design of APIs quite
> horrible, so the only sane way to offer both is to make one the *main*
> representation and the other one a convenience thing to create the first.
>
> It really does not make sense to make every XQJ implementation offer
> convenience conversion from trees to strings. And most of our discussion
> carries over to the question "which should be the main representation of
> queries in the XQJ API" ?

Instead of revising the XQJ API, it's probably better to have a separate
specification for alternative representations of queries. (That was there's a
separate SQLJ specification, instead of shoehorning early checking of queries
into the JDBC API.)

• Follow-Ups:
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Burak Emir <Burak.Emir@e...>

• References:
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Burak Emir <Burak.Emir@e...>

• Prev by Date: Re: problem saving microsoft.xmldom object
• Next by Date: Re: Early Draft Review: XQuery for Java (JSR 225)
• Previous by thread: Re: Early Draft Review: XQuery for Java (JSR 225)
• Next by thread: Re: Early Draft Review: XQuery for Java (JSR 225)
• Index(es):
  • Date
  • Thread