Re: XML versus Relational Database

[Charles Reitzel <creitzel@mediaone.net>]

On Thu, 01 Feb 2001, Benjamin Franz wrote:
>On Thu, 1 Feb 2001, Caroline Clewlow wrote:
>> Isn't the issue that XML is not designed as a mechansim 
>>to store data, but a mechanism to allow data to be 
>>provided in a common format that can be understood 
>>by disparate systems?
>> 
>This is an issue I just brought up on the XSL-LIST as 
>'Paradigm clash between XML as document and as database'. 
>People like myself see XML as a description of a database
>structure with XML *files* themselves just being a common
> import/export format. I see DOM, XPath and similar 
>programmatic APIs as actually more fundamental than the 
>flat XML text files.

Yup.  All points that need occasional restatement.

>This difference in 'think' is why you see (what is to me)
>sillyness like hardcoding stylesheet directives in XML 
>datafiles when that is 3.141592 radians away from what 
>*I* need to do - which is apply arbitrary different
>stylesheets to common XML data. In my world, it approaches 
>zero utility to hardcode stylesheet callouts in the XML data.

Negative utility even...

>The clash in paradigm is causing great pain for those of 
>us who want to do 'great things' with XML because the 
>'XML database' vendors seem to have come from the SGML 
>worldview of a 'database of XML documents' rather than
>the view of 'XML document as database'. This causes things 
>like XSLT to scale rather badly with every production level
>'native' XML database I am aware of today. All of them appear 
>to have realized the 'error of their ways' - but their 
>solutions are still 6 months to a year out by their own
>estimates.

My own solution is an application that, based on meta-data, knows who wants
data in a given XML file, locates a good XSLT stylesheet, and renders the
output.  I.e. XSLT is a great tool, but needs to be used offline is all.

>Right now, the only *scalable* solution (ie in my case 
>capable of handling more than a megabyte of XML data being
> rendered to web pages in a sub-second response environment 
>on server class multi-cpu ix86 hardware) I am aware of is XML
> mapped onto SQL. And a butt-ugly solution it is.
>
>And *aggressive* caching.

We try to remain flexible.  So if the subscribing website (this is
straight-up syndication, here) specifies a stylesheet other than the
default, the result will be kept and regenerated only if either input -
stylesheet or XML instance document - has been updated.  Thus, only the
first customer gets the 3+ second hit.

Also, although we make metadata available in XML format, we sure as heck
don't store it that way.  Also, on the query servers, because we only
replicate every hour, we can cache query results on a proxy by setting the
Expires HTTP entity header in the response.

Charles Reitzel

>Benjamin Franz
>
>... with proper design, the features come cheaply. This 
>approach is arduous, but continues to succeed.
>
>                                     ---Dennis Ritchie
>