[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: Wed, 30 Jun 2004 14:14:58 -0700
• References: <20040629081952.HGFO2927.mta05-svc.ntlworld.com@Turtle> <017101c45e32$ba6f0430$1601a8c0@DURANTE> <40E26C32.5030802@e...>

Burak Emir wrote:
> But nobody talked about "strings or not" for what happens between client
> and server. .

That's my point -- what happens between an XQJ client (consumer) and an XQuery
engine/server/provider is relevant to the "strings or not" API discussion.

My example used a client and server because that architecture is well-suited to
this division of labor -- one program consuming services provided by another.
(As an alternative, you can embed an XQuery engine in the same process as your
application, but then you might prefer to use an input stream instead of an XQJ
interface to the engine.)

>> The programmer should not be concerned at all with these implementation
choices

Disagree. The architecture for deployment affects design and programming choices
(details below).

> >For single-execution queries, the XQJ client program passes the query string
to
> >the driver for each execution of the query (or the abstract syntax tree
> >alternative).
> >
> >For repetitive, stored queries, we don't pass a string each time so we don't
> >parse the query repetitively. We parse it once, and on subsequent executions
of
> >the query, we pass execution time parameters.
> >
> >
> This does not impose any constraint on how you represent queries and how
> the programmer passes them to the interface.
>
> It rather defines what should happen upon
> "preparedQuery.setArgument(1,foo); "

It doesn't impose a constraint, but the elegance of the "strings or not" choice
is not an overriding concern for recurring queries (parse once, execute many
times).

> >>The benefit of a custom syntax/protocol is that it gives earlier validation.

Agreed, for example doing compile-time type checking with a current schema.

> Sure you (the xquery server implementors) can, but the user who wants to
> validate them without a server cannot. Same for testing, debugging,
> pretty-printing,  <insert what="high-level programming activity"
> where="here"/> ...

Testing and debugging of an XQJ program will be quite limited without connecting
to an XQuery engine/server.

> More to the point, should the XQJ API support different implementation choices
or use low-level representations that dictate only one?

It makes sense to offer an alternative to passing strings, but not a replacement
for passing strings.

> what happens between client and server should really not have any influence on
the API.

It does. Compare two scenarios. In the first case, everything is completely
contained on my laptop -- XQJ client, XQuery engine, and a collection of 3000
documents. In the second case, an XQJ client on my laptop connects to an XQuery
server run by a large organization having a collection of millions of documents,
with some documents in concurrent use by hundreds of users.

In the latter case, scalability and security become an issue. The API, and the
formats and protocols for communication between the query client and XQuery
engine, must scale and provide options such as connection pooling, caching query
results, setting query timeouts and so on.

The API must be flexible enough to be effective in either scenario.

> >2. Someone building an XQuery server will often prefer a language-neutral
> >solution for servicing clients. Come one, come all -- Java clients, C#, Perl,
> >whatever.
> >
> It's off topic, but I agree - but then I also think every vendor will
> nevertheless supply his own XQJ implementations for Java (and the Dotnet
> equivalent).

I'm not sure what you mean by vendors supplying XQJ implementations. Most
vendors of  XQuery (or SQL/XQuery) servers will offer XQJ drivers and .Net data
providers. There will also be XQJ drivers from ISVs and open source projects.

> > XQuery servers, like HTTP servers, will serve a broader audience if they
employ language-neutral and platform-neutral
> >technologies.
> >
> Sure, but the XQJ API is completely independent from these issues.

Not if altering the API affects the interoperability of data or parameters
passed between the XQJ client (XQuery consumer) and XQuery engine.

Suppose for example, we modified the API so XQuery engines return query results
(XQResultSequence) as a binary stream in Apple .img  format. Sure, we can
probably find Linux / Solaris and PC libraries with code for reading .img  data,
but is that really a language-neutral and platform-neutral API choice?

APIs are not independent of language-neutral and platform-neutral
considerations.

• References:
  • RE: Early Draft Review: XQuery for Java (JSR 225)
    • From: "Michael Kay" <michael.h.kay@n...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: "Ken North" <kennorth@s...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Burak Emir <Burak.Emir@e...>

• Prev by Date: ANN: Oracle XDK 10.1.0.2.0 for AIX, HP-UX64 and LINUX production release
• Next by Date: Re: hi all
• Previous by thread: Re: Early Draft Review: XQuery for Java (JSR 225)
• Next by thread: loose coupling, was Re: Early Draft Review: XQuery forJava (JSR 225)
• Index(es):
  • Date
  • Thread