[
Lists Home |
Date Index |
Thread Index
]
On 9/30/05, Costello, Roger L. <costello@mitre.org> 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
|
