[
Lists Home |
Date Index |
Thread Index
]
> I'm interested in your reasons why not. I can think of some.
I'm thinking of reports, which are classically unnormalized. XML data for a
report may be divided into pages. For a two-page bill, the customer name
and account ID may appear twice (once on each page). Yes, you could use
ID/IDREF or key/keyRef to avoid the duplication in the XML source, but that
seems like overkill in most cases.
Also, reports often contain parent-child relations that are implied by
colocation of data (like the name/address example I gave at the beginning of
the thread). While it's perhaps not good XML design to flatten those
hierarchies by a transform, I would expect it to happen nonetheless.
> OTOH if documents are unjoined normalized
> selections and
> projections from the original relational data, updates from
> the documents
> would be simpler. Or is this just hopelessly naive?
If you have access to the original data, yes. If you only have secondary
access through projected data documents, then you're stuck with having to
augment the information you recieve in order to automate it. It may be an
uncommon situation for internal applications that you can't get access to
the prime data source, although I've worked at companies large enough where
that was the case (either for security reasons, or for bureaucratic ones).
Another example is where you're required to consume standard XML documents
used for cross-business data interchange. While you might assume the
promulgating standards body behind the document model would have a clue
about avoiding data replication and to use hierarchies or references to
denote relations, I think practice will show that you might assume too much.
I'll now defer to the more promiscuous among the list (the XML
consultants), who might wish to take a turn at the podium and describe what
driving in the fast (and loose) lane is like.
|
