[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: A standard approach to glueing together reusableXML fragm


how to approach a hedgehog
--- Rick Marshall <rjm@z...> wrote:

> <customer>
> 	<name>COMPANY X</name>
> 	<town>SOMEWHERE</town>
> 	<order>
> 		<part>ABC123</part>
> 		<quantity>2</quantity>
> 	</order>
> 	<order>
> 		<part>ABC234</part>
> 		<quantity>4</quantity>
> 	</order>
> </customer>
> 
> just isn't going to be a relational form as there's
> no way to determine
> a priori what the normalised records are....

> so without some semantics you can't represent
> relational tables with the
> natural tree structure of xml.

Yup.  The hierarchical approach that XML supports
allows you to not worry about the sometimes
challenging problem of figuring out what the keys
would be in a normalization that will allow you to get
back the information you put in.  It's sortof like the
fox and hedgehog: the relational model has a many
tricks for defining relationships among components,
but you have to be clever to use it well; XML has only
one trick ("containment") but it's a pretty powerful
one.  Of course, not all data fit the "natural tree
structure of XML" but a lot of interesting examples
do.

The downside, which I think is the point of this
thread (I haven't read the whole thing!) is that XML's
"one big trick" works best if the document as a whole
is the unit of analysis and storage.  Once you start
composing compound documents out of individual
entities or need to update specific
elements/attributes inside an entity, things start to
get very ugly and there's little in the way of a
theoretical model such as Codd developed to guide you.
For example, there is a more or less irresolveable
muddle between the XML syntax level model of entity
declarations and references and the
Infoset/XPath/XQuery model in which these are assumed
to have been resolved.  (DOM tries to play on both
sides of the street, but that part of its conceptual
model is very ugly). 

XQuery is probably a great breakthrough here by
allowing both the implicit containment relationships
that the relational model lacks and allowing documents
to be composed by a Join operation on shared values,
which AFAIK is the most profoundly powerful aspect of
the RM.  Whether XQuery implementations can be written
in a way so as to make this practical for
terabyte-scale databases is yet to be seen ... but I
have to assume that (pulling numbers out of the air) a
3-way Join of hierarchical document collections will
be more practical than 100-way joins across normalized
relations containing the components of complex
documents such as aircraft maintenance manuals.


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.