Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Better design: "flatter is better" or "nesting is better"
 On 9/30/05, Costello, Roger L. <costello@m...> wrote: > Hi Folks, > > Many thanks for your excellent comments! > > First, I will attempt to summarize the points that were raised in your > comments. Then, in the spirit of the philosopher Karl Popper I will boldly > propose a solution to the question: "How should XML documents be designed?" <snip/> > > To recap - when designing XML: > - be practical; > - be simple; > - don't use unnecessary tags; > - design your XML to work well with your > applications *today*; > - most likely, "flatter is better". > > Comments? /Roger > Roger, I've spent a fair amount of time working on design principles that might apply when building applications that span XML, relational databases and OO technologies. Our main application has a pretty low amount of conversion and data management needed to move data from the back end to the user and back again and my goal is to keep the application as flexible as possible and as efficient as possible. As a result this is an area where I've got a lot of interest. I have no real disagreement with what you've got so far, but perhaps some expansion: In general, I think you've really got to look at where the data is being used before making any recommendations on how to structure it. In particular, if the data is being stored in a highly normalized RDB then any XML data that is being created or manipulated close to that portion of the app. should likely reflect that structure. Conversely, if the data is being presented to the user via some GUI then it makes sense to at least have some temporary instance XML that is close to the denormalized GUI it is targeted for. In between we might have an intermediate transport format. Thus, I fined we end up with three main XML designs: 1) highly normalized, flat structures for use in and around the RDB management layer; 2) composite object models that encapsulate domain specific business rules on how the normalized data structures are used together and perhaps reflect some of these rules within the data structure; 3) presentation specific structures that reflect some (perhaps abstract) denormalized, hierarchical presentation model. Each of these is used as needed and XSLT and SAX parsers convert between them. If I've got to pick a model for exchange with external entities it could be any of these depending on the level of integration and the purpose for which we are exchanging the data. The more automated the exchange, the more likely the model is going to be close to the normalized back end representation (by definition, that is already supposed to be a granular representation known to work in your domain.) The more humans involved in the exchange, the more likely I'm going to be looking at some structure that matches a denormalized hierarchical representation; this format should be a closer match to a human readable document. So I might perhaps add a meta design principle: design for the problem at hand and not according to some overall design principle... -- Peter Hunsberger 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
