OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] A standard approach to glueing together reusable XML fra

[ Lists Home | Date Index | Thread Index ]

I doubt you are in the minority.  There have been multiple threads 
here comparing implementation strategies for so-called "XML Databases". 
Relational systems are mature with respect to optimization, indexing, 
and have a large and skilled user community.  They scale nicely for 
very large systems for all the reasons we know about.  XML databases 
using non-relational implementations exist and are progressing 
nicely but are not as mature nor as experienced.  

XML is meaningless.  XML-only is the same.  Nice format for archival, 
on the wire representation, and human comprehension.  The infoset-level 
data structures are ok for the jobs most put them to, in-memory work 
for transformation, getting and setting limited size value sets, and 
so forth.  Useful when a large system or set of systems must cooperate 
to perform tasks at the loose level of represenational state transfer. 

Given that entities work, fragments work.  The problems are indexing 
and normalization just above the metal, but a whole host of social 
issues after that which are the same for relational or any other 
implementation framework.  I'm always glad to see anyone take up 
this topic. Fresh eyes and all that.

The markup community at large knows all of this, has known all of 
this since before SGML, and continues to explore options.  We do not 
limit ourselves in any meaningful way except to insist on a 
meaningless standard, and for integration of very large systems, 
that has made all the difference.  In other words, try it in 
a relational system without markup and see the other side of the 
difficulties.  Because many of us have worked with or implemented 
document management systems for three decades, we are well-aware.

What is a 'document file'?

len


From: Mitch Amiano [mailto:mamiano@nc.rr.com]

Ok, I'll just come out and say "that's stupid". 

"XML only" simply doesn't make sense. There is no such thing. 
It seems contrary to the whole point.
But maybe I'm in a minority.

lbradshaw@dbex.com wrote:

> 
> Ummm, the situation presented is that an XML only solution set can 
> provide the needed functionality, response time, and other capabilities.
> 
> No worries here that I can do this using a relational DBMS, normal 
> forms, etc. But doing it only using XML constructs, and tools specific 
> to XML, does not seem doable, reasonable, appropriate or supportable 
> over time.
> 
> Someone told me, verbally, and emphatically, that it is doable in XML 
> only constructs, to which I replied "Show me." and from whom no such 
> demonstration has been forthcoming. I think they said that because the 
> XML tech community, as a general rule, limits it discussions to 
> generalizations specific to small data stores, which is fine in and of 
> itself, but which leads to grave errors otherwise.
> 
> Also, I have to smile when someone says something like "implement XML 
> within a relational database".
> 
> Thanks for your response, and in my opinion you are exactly and 
> precisely correct. Delivering this functionality on this scale using the 
> currently available computer hardware and connectivity almost without 
> exception requires the use of normal forms, and normal forms are best 
> implemented in a dbms, not a document file.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS