June 28, 2005

via Techworld.com | Oracle pitches database future on XML

Techworld.com - Oracle pitches database future on XML

Oracle will support advanced XML features in the imminent release of its 10g database, including the emerging W3C standard XQuery for accessing unstructured XML data, the company has announced.

Actually, the only reason I am posting this (if anybody suspected there was a chance Oracle would not support XQuery theres a really good chance you're an idiot... actually, the author of this article might be a prime candidate for such a distinction. Reason to follow...)

As I began to read through this article to decide if it was even worth a post (again, I think we all either thought they already had announced it or if they hadn't assumed the obvious and simply didn't care enough to watch this space for any announcements, for or against) I began to recognize we had a real genius on our hands and decided it was worth the post if not for the laugh, the possibility that maybe it would help bring recognition to those in charge at Techworld.com to get this guy as far away from a keyboard as possible before he does any permanent damage. Two possibilities... actually three:

1) He's the relative of somebody high up and got the job as a favor to his poor mother who has had to deal with him his whole life
2) He's drunk
3) Both

Let's run with #3 as it seems the most likely. The first item up for "I'm an idiot" bid:

About 80 to 85 percent of corporate data is unstructured, in the form of word processing documents, PDF files and content management systems, according to industry observers. XML is designed to handle such data by arranging it into hierarchies, rather than distorting it into the tables used by relational databases.

First problem: Since when have word processing documents and PDF files had anything in common with content management systems (other than the possibility they might be stored in one at some point)? Is he suggesting that a CMS is an actual document format? And what decides what is and what isnt a CMS? Could be anything from your kid sister that you pay to index your comic books and baseball cards to a multi-million dollar data warehouse and everywhere in between.

Even if the benefit of the doubt is given and we assume he is suggesting "stored within a CMS" even this doesn't make a whole lot of sense as, again, what type of CMS are you refering to and, still, what do any possible answers to this question have to do with a specific document format like PDF? Personally, when I hear the phrase "Corporate Data" I don't think documents at all and instead data bases like Oracle and SQL Server. And if its in either of these (or any of the others) then its stored in a relational format for a reason! Of course that reason is not a "place to put it while we find something better to work with as a document format that makes sense." and instead "a time proven kick a$$ solution for secured programmable storage of and secured programmable access to the raw data that keeps your company tickin' day in and day out."

There's so much disconnection in the above quoted statement you simply can't lump the referenced data all together into "Corporate Documents" and yet this is where the argument seems to point to as the source of the problem... the inability to take a document like a Word .doc or Adobe PDF and easily serialize these into a relational format found in a relational database for the above defined storage and access. Usually, any "data" found in a corporate document came from the database in the first place, not from the Word document itself. And yet even if storage of these documents that have been serialized to a relational format within a database was the problem the answer to this problem is "why would you want to do that? Just store it as whatever binary format implementation the database you use extends and get on with it. Want to search through it? Do a full text search via your database API or through and indexing extension. Problem solved. Wait, what was the problem again?"

Point: If you are using a database which doesnt allow you the ability to store file system objects like Word and PDF files in their original, untouched format, instead forcing a conversion to a relational table data format you might want to consider an upgrade at some point in the near-to-immediatte-to-you're-probably-already-too-late-cuz-you're-likely-bankrupt-by-now-anyway future. Just a thought.

Question: Which industry insider gave him this information in the first place????!!! Probably somebody who got a good laugh out of knowing he would print it as is, no questions... I'd have done the same thing probably if for no other reason than to bring a bit of entertainment into the space where frustration is a more common occupant.

Ok, moving forward:

In the past, approaches based on DOM (Document Object Model) or XSLT (eXtensible Stylesheet Language Transformations) have been used to query XML databases;

XML databases? Which ones? As Far As I Know there are no XML databases that use DOM or XSLT as a native query language. XPath maybe, but DOM and XSLT? Maybe I'm wrong and some genius decided that the Document Object Model was far superior to something like XPath which was designed specifically for the purpose of querying an XML infoset for a specific set of nodes based on a given criteria expressed in the given XPath statement to then return these nodes for further processing. But now you would have to serialize the results of your DOM "query" to XML which is really no big deal with most DOM implementations but using the DOM API as a query language was never, as far as I know, a design criteria... that's what XPath (in regards to XML that is) was designed for when all these technologies we now take for granted were in there early development and implementation stages.

But regardless of how it gets to us and in its XML format what to do now with the returned set of nodes? XSLT would be a good candidate to now transform the contained information into something usable... but at this stage we are no longer in the database and instead outside the database which is where the returned nodeset was sent as part of the XPath-based query transaction... Besides XSLT doesn't have its own query language. It uses XPath just like what (I assume) most if not all XML databases of old used as the primary query language to access the contained datasets. But I can't say that I have experience with each and every XML database of old and as such I have to leave room for the possibility that somebody, somewhere, implemented an XML database that chose DOM and XSLT[1] over XPath...

Dear God I hope not.

XQuery needs a fraction of the code of such approaches, and can address more types of data, among other advantages, according to Oracle.

Hey, theres a safe bet... if you are using DOM or XSLT as the primary query language for your XML database I'd bet you'd find that a lot less lines of code would be necessary to perform that same query using XQuery. More types of data? Sure! But it might be more accurate to state "any data whatsoever, regardless of its type!"[2]

You might also find that hitting the nail with a hammer instead of your forehead might better your chances of accomplishing the task of driving the nail into place with the added benefit of not adding any points to your idiot factor. Unfortunately I think my advice might be a little too late... At least I tried. If nothing else I can always find comfort in knowing I did my best with the situation I was placed in front of.

"NO!!!!! USE A HAMM... ohhhhh... hmmm. well, nevermind... How's your head feeling? Ya think that mark will be permanent?"

More than likely as I doubt it was from this instance that the mark... make that divot... first came into existence.

Ok, so maybe I am being picky about the difference between an XML database and an XML infoset. But I don't think so. If you are having troubles understanding the difference (and don't consider yourself somewhat knowledgable in the area of XML... those who do not are not a part of the group I am speaking to here so don't feel bad if you are reading this and claim no knowledge of what XML is much less an XML database or infoset...) you may want to think about starting over at the beginning. Hey, good luck with <-- that course... it seems you might need it. ;)

Peace, Love, "Quit smokin' that Dope!" :)

[1] Technically impossible given XPath is a required piece of the XSLT domain.

[2] Actually, in the case of DOM thats not true, but while DOM is something you will find in places where documents based on markup tags like HTML and XML (and as such can be serialized to the DOM format) exist (like a browser) its not exactly the kind of interface one would present as a typical user query language and rather an API-styled interface into the contents of a document for purposes other than a simple query... e.g. to change the value of an element or attribute or add dynamic content such that it renders without need for a refresh, etc...]