ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
RE: [xml-dev] Normalizing XML [was: XML information modeling best practices]
by Jeff Lowery other posts by this author
May 2 2002 6:25PM messages near this date
Re: [xml-dev] Web Service Business Questions | RE: [xml-dev] SOAP and the Web
>  > But all this presupposes that we are designing XML 
>  documents for storage and
>  > query. Most XML documents are designed for messaging of 
>  some kind (between
>  > humans or between software components). Within the context 
>  of a message,
>  > duplication is far less of a problem, for example it 
>  doesn't matter if I
>  > hold product code, description, and price as part of each 
>  order-line in an
>  > order. Many XML databases are actually archives of such messages, so
>  > duplication of data is a fact of life; and since it's an 
>  archive, the update
>  > problem doesn't arise.
>  
>  This is the conclusion I came to.

With all due respect, I couldn't disagree more. In the case of
roundtripping, there is the classic problem of update anomalies. Since the
recieving application may not know what is duplicate (certainly a schema
won't give a clue), there's the risk that some duplicates will be changed by
the receiving application but not others. That means that there has to be
some logic embedded somewhere that (probably in the originating applicaiton)
that performs a validation check that all duplicate values have been
modified; otherwise, you have to pick and choose which values to ignore.
That's not easy, because one of the values may have gotten changed back to
it's original state: was that intended as the 'final' value? Or was it just
a sloppy partial update of other duplicates?

I think if you exchanging data documents, especially between third-party
applications, duplicates should be avoided. You can't denote them in a
schema (unless you key/keyref them all), so the result is that you have an
implicit (or narrative) understanding of what is duplicate. Bad, bad, bad.

For views, though, I agree: normalization isn't necessary.

-----------------------------------------------------------------
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://lists.xml.org/ob/adm.pl> 

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved