[
Lists Home |
Date Index |
Thread Index
]
Ken North wrote:
>>The benefit of a string interface is that it gives looser coupling between
>>systems. The benefit of a custom syntax/protocol is that it gives earlier
>>validation. The experience of the last few years is that loose coupling
>>tends to win, across most application scenarios. Hence XML.
>>
>>
>
>My comment was the argument about "strings or not" is moot (as in "deprived of
>practical relevance") when we're talking about stored queries -- as opposed to
>ad hoc, single-execution queries.
>
>
But nobody talked about "strings or not" for what happens between client
and server. The programmer should not be concerned at all with these
implementation choices.
>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); "
>>The benefit of a custom syntax/protocol is that it gives earlier validation.
>>
>>
>
>In the case of [JDBC | XQJ], we can use strings and delegate validation to the
>[SQL | XQuery] engine. We can use prepared statements (JDBC) or prepared
>expressions (XQJ) as a separate, distinct process before we execute a query.
>That gives us pre-execution validation and exception checking. (Pre-execution in
>this context is a reference to query execution, not program execution.)
>
>
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"/> ...
Ken North wrote also:
>The XQJ client uses a driver to connect and submit queries to an XQuery engine.
>A typical scenario is a client-server architecture with the query engine running
>on a separate machine from clients that submit queries across the wire (in this
>case XQJ clients). The XQuery server and XQJ client execute on separate
>computers, or in separate processes if they reside on a single computer.
>
Since the XQJ client is already a separate process, why not do some
validation here ?
More to the point, should the XQJ API support different implementation
choices or use low-level representations that dictate only one?
>Any Java byte arrays can be "serialized" to a sequence of bytes (just
>> don't call the "serialize" method, but write something like
>> "toMyCustomBLOB()").
>
>
>
>1. The client (XQJ or otherwise) has to be pass the query to the XQuery engine
>using a mutually-understood format. If Java clients are not passing query
>strings, then there needs to be a spec for queries represented as CustomBLOBs.
>
>
>
the CustomBLOB was just an example to say that the XQJ implementers are
free to choose what they want. Therefor what happens between client and
server should really not have any influence on the API.
>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). Language-neutral can mean a binary spec or an UTF-8 string,
it does not necessarily mean "you must use query strings as is".
>3. If we must choose between elegance and interoperability, my vote is for
>interoperability. SOAP and XML RPCs emerged in part because of interoperability
>issues with COM+ and CORBA. 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. COM+
was never intended to be interoperable, and CORBA is heavyweight because
it wants to solve the problem of interoperability. Lightweight stuff
like SOAP and XML RPC have the advantage of being XML, hence specifying
character encodings or escaping unicode characters in a document is
standardized and easy.
With XQJ, the aim is to provide an interface to XQuery for programmers.
Programmers like interoperability, they do not want to care whether the
server has 8 registers or 32 and what the endianness is. They like to
parse COBOL or ABAP query in ASCII and turn it into an XQuery (parse
tree). They like to have a single place where column (or element) names
are kept. They like to encapsulate everything database specific in a
high-level API, so *their* users don't even think of XML and queries
anymore. All this is made easy with a tree-like interface.
cheers,
Burak
|
