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

Caught napping!

  • To: xml-dev@l...
  • Subject: Caught napping!
  • From: Linda Grimaldi <lgrimaldi@n...>
  • Date: Wed, 07 Nov 2001 09:26:08 -0700
  • Delivered-to: xml-dev@m...
  • Thread-index: AcFnqOfbbVgk3mTARRyq/eV/HDdbsw==
  • Thread-topic: Caught napping!

caught napping
I just picked up on the database decision tree thread.  Life has been
hectic, but boy was I remiss.  Hope it's not too late to throw my 2
cents in- you know I'm going to anyway...

I was generally really impressed by the discussion, but I think there
might be an aspect to it that is missing.  It's a little more "Zen of
XML" oriented, but I think it is worth considering.

XML is a carrier of data plus context, data plus metadata.  This is
obvious, but is often lost in document design.  When I look at a lot of
schemas out there these days, they are often blatantly influenced by an
underlying relational mentality.  This is not  a bad thing if your
eventual target is an existing relational database.  My question is
this: If the ersistence mechanism used were not relational, but if it
treated XML as XML in a very fundamental way- symmetrically handling
data and metadata, for example- would schema design change in any
fundamental ways, particularly for "new" data?  We tend to put the
schema before the persistence choice.  If we did it the other way
around, would anything change?  Referential integrity, for example,
between such mundane objects as customers and purchase orders might be
accomodated by treating the customer and his list of POs as a single
doc.  Or, if the implementation is efficient enough in terms of data
footprint, by replicating customer data on each PO.

We tend to shape our data to fit our container, not the other way
around. In general, this was because we had no choice. Many a wonderful
object model has gone astray when tossed upon the shoals of RDBMS design
constraints.  (O/R mapping tools helped, but the solution was less than
satisfactory and a real pain to maintain.)  The ability to persist and
manage XML "natively" may now give us the choice.  The analogy with
OODBMS is not inappropriate, but XML has the advantage of being the
preferred transport mechanism as well, and old-style OODBMS still
constrained schema.

Does this make any sense?

Linda

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.