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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Granularity

On 06/01/2012 00:14, Len Bullard wrote:
8044FBBA608F4BAEACD54B9453165FD9@LenBullardPro" type="cite">

When building XML systems, how do you choose the best granularity for storing and retrieving fragments? 


Not entirely sure what you mean by a "fragment": is your question "how much data goes in one XML document"? That is indeed a difficult question. The decision tends to be made for operational reasons rather than pure data modelling reasons, and is thus an example of how XML fails to make a clear distinction between logical and physical design in the way that database people have been advocating for decades.

Many XML databases work best when you have lots of small documents; a few work well when you have one giant all-embracing document. That's a factor that can't be ignored in your design, even though one would like to.

Another factor is that the document is often the unit of validation. Cross-document validation is generally awkward.

Similarly, the fact that documents are the unit of interchange affects the decision (sometimes it rightly dominates the decision).

There are many applications where "one document per business object" works well: e.g. in a system managing data about hotels, one document per hotel. But where do you put the information about room availability? One document per hotel per night? It starts to become very arbitrary. That's one reason why there will always be a need for transformations.

Michael Kay

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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

Copyright 1993-2007 XML.org. This site is hosted by OASIS