Re: XQuery question

"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:b9e86v$ie0us$1_at_ID-152540.news.dfncis.de...
> SQL '99 it's called WITH RECURSIVE. IBM db2 decided that recursive is
> superfluous and didn't implement the full options (which are probably
> more powerfuil than you need for transitive closure)

I honestly don't know why SQL standards are published at all. No vendors implement them; some declare before the standard is even published they won't be implementing large portions of them. The standards are not available on the web for study, so few people actually know what they say or could find out if they were curious. Whereas web standards are freely available and we see precise statements from vendors detailing any deviations from published standards, which are almost always extensions and not subtractions. It seems not to be meaningful to speak of SQL at all, but rather of Oracle SQL, DB2 SQL or some other dialect.

At the same time, I should have known that, and thanks. Like Rip van Winkle, I only wake up every so many years and pay attention to SQL standards work, because it never seems relevant to actual practice.

> Plus I don't really see how mixing orthogonal concerns like logical data
> structure and physical data encoding (representaition, viz. the bloody
> tags) is going to help me in any way shape or form. Dijkstra told us we
> can do better decades ago, viz. separtion of concerns, and Codd was of
> the same opinion.
>
> This leads in my opinion to way unnecessary complexity.

It is necessary complexity, but in a different problem domain. The basic rationale for XML, as for SGML before it, is to provide a way to mark up text documents (by this I mean books, manuals, lessons, certain web pages, etc.) so that the added information is sufficiently abstract to permit more than one kind of representation and sufficiently specific to allow portions of the document(s) to be transformed and recombined into new works. In written works like this, order is significant; there is nothing to tell which of two paragraphs should appear before the other except the order in which they appear in the document, and ease of editing dictates that there should not be. Written works are well-suited to a hierarchical representation with occasional network references. For an example of the latter, consider a forward reference to a chapter which, in the course of writing, will change names, numbers, etc.

When XML documents are used to represent an analog of relational data, then a number of artifacts inherited from the domain of written works become superflous. Order, accidental whitespace, all useless. Hierarchy is simply a naming convention, e.g., emp{name{first,last},id}* is equivalent to the tuple (emp.name.first,emp.name.last,emp.id). Since all items are named, their internal order is not significant (though this kind of accidental order is shared with relational database) and likewise the order of the tuples. It is not surprising that database people look at these things as unnecessary. They are.

At the same time, there is a reasonable justification for using XML documents as temporary vessels for relational data. XML documents can encapsulate transactions during the real-world time delay between the customer's intention and absorbtion into a database. Lots of the world's business doesn't fit the model of an online 24/7 transaction processor. XML documents can capture views or reports from relational data in the intermediate stage between query results delivered to a program and graphics delivered to a human user.

It is true that XML is sometimes applied where it is not appropriate. For example, if a server program performs a query and converts the results to HTML for delivery to the client, what is the point of converting the query results to XML and then transforming the XML to HTML? It is simply extra overhead. On the other hand, if the XML representation can be delivered directly to the client and the work of transforming the information to a graphical representation thereby offloaded from the server, the XML intermediary is justified. It is all well and good to assert that some other means of encoding might be more efficient, but XML exists, it has the necessary tools infrastructure and is supported by current client software.

I believe database professionals often criticize XML because they see it as an alternative and inferior database technology. But XML is not a database technology, except in the sense that any collection of information is a database. Certainly it is not a database management technology, and the existence of a query/transform engine doesn't make it so.

> Transitive closure is not a relational term, I knew that from my first
> introductory course in algebra, before I knew what a dataabse was.

Well, good for you. ;-}

Thanks, otherwise, for your informative reply.

Bob Received on Fri May 09 2003 - 07:22:01 CEST