[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)
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|