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

Re: Designing XML to Support Information Evolution


relational reporting

We are finding there are two different drivers in the XML usage:
*) exchange, actually exchange of (roughly) the same data in different contexts, across different systems and organizational boundaries.
*) as the 'evolved' information itself - representing the gained functionality and value with which key business entities emergy from being orchestrated within an environment.

The later, with audit trails and the need to reproduce that context at some later date, has been where i've seen production relational environments become cumbersome.  
Requirements grow and change and/or success increases scope for a relational model over time and - all too often - dull the design intent under which the relationships were modeled making each new integration more brittle, the model less normalized based on competing access paths.

We have found good success with a mixed design using versioned xml for the transactional context with only key relationships between key entities are expressed in a way of which Codd or Date would approve.

Context and hierarchy seem to serve well within a business transaction - relationship better serve in comparisons and analysis across those transactions.  We are not having great success with xquery for the later, not yet anyway, though the tools in this arena continue to improve.  

/james



Michael Champion <mc@x...>

05/17/2004 10:28 AM

To
xml-dev DEV' <xml-dev@l...>
cc
Subject
Re: Designing XML to Support Information Evolution






On May 17, 2004, at 10:20 AM, Roger L. Costello wrote:

>  
> 1. How you structure your information in XML has a tremendous impact  
> on the processing of the information.
>  
> 2. Hierarchy makes processing information hard!  There exists a  
> relationship between hierarchy of information and the complexity of  
> code to process the information.  The relationship is roughly: the  
> greater the hierarchy, the greater the complexity of code to process  
> the information  (Some hierarchy is good, of course.  But the amount  
> of hierarchy that is good is probably much less than one might  
> imagine, certainly less than I thought, as described above.)
>  
> 3. Flat data is good data!  Flatten out the hierarchy of your data.   
> It makes the information flexible and easier to process.
>  
> 4. Order hurts!  Requiring a strict order of the information makes for  
> a brittle design.  It is only when I allowed the lots and pickers to  
> occur in any order that the flexibility and simplicity kicked in.
>  
> Comments?  /Roger

I'm wondering if you haven't rediscovered the relational model?  (Or at  
least you've discovered the importance of "normalization" in the  
relational sense even in the XML context).  But why bother with XML at  
all (except maybe as a data interchange format) here?  Wouldn't a  
relational reporting tool be much easier than XSLT with this data  
structure?

 C.J. Date gave a speech recently  
http://searchdatabase.techtarget.com/originalContent/
0,289142,sid13_gci962948,00.html complaining that XML is trying to take  
over the world.  Maybe he has a point :-)  I certainly don't agree with  
all he's saying, but if you are modeling data rather than exchanging  
documents, I would think that the relational model would be the  
starting point until you run into its walls.

Clearly if flexibility is paramount, order and hierarchy are a pain,  
and there's not much gain *if* you have unique identies for everything  
and the identity is all you need to know to figure out what to do with  
the information.

 On the other hand, if *context* is important, i.e. the intepretation /  
semantics / meaning / processing paradigm of some bit of information  
depends more on where it stands in relation to other information, then  
order and hierarchy are critical.   That's where the XML "data model"  
(by which I mean "fairly deeply hierarchical labelled trees in which  
order is preserved", not the InfoSet per se) comes into its own.




-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>



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.