Cart
[Home] [By Thread] [By Date] [Recent Entries]
Jeff Lowery <Jeff.Lowery@c...> wrote: > For me, it's not an issue of "how do I represent this data?", > but "how do I define this data so that it can be represented > several different ways?" (and efficiently). Boy, that's a $64,000 question... > There's certainly a lot of effort being expended in the > development of mapping between relational and object models, > and between object models and XML document models right now. > The problem is that all mapping technologies > seem to require a primacy of one model over the other. For > example, I can > generate class defs from a document model (Castor, JAXB), or > I can generate document models from class definitions (JiBX). > > Is there a universal mapping language that can be used across > all data representations (a.k.a. mediums)? At the risk of > sounding like a thrall of certain fascists, I really do think > that any such universal mapping language will, at it's heart, > be formulated on relational algebra. That's not to say that > all models must conform to integrity constraints under all > operations; what it does say is that those potential > integrity violations are understood and handled correctly > when data is moved from one representation to the next > through the defined mapping operations. Hmm, I might even grant integrity constraint conformation (99.99% or the time). What I wouldn't necessarily expect is normalizations that conforms to what experts in the current relational world might expect: I'm starting to believe that data normalization and metadata normalization are orthogonal to each other. Schemas that optimize one may do so at the expense of the other. However, having (properly, whatever that might mean) done the normalization either way it seems that data will conform to the constraints that result (more or less by definition)... Eg.; there are known relational patterns for normalizing a non-cyclical hierarchical structure. If I use one of these to organize my data based on it's structural relationships the resulting data normalization may be rather different than if I apply standard data normalization to the same domain... > I believe we're a long way from getting a mapping language > that's both universal and easy to use. It may be a language > with many dialects, each suited from a particular set of > representations and mapping direction. It does seem, though, > that the current technique of writing one-off Java, C++, and > XSLT algorithms to perform these representational transforms > is horribly error prone. > True, and yet they all the domains agree on so many basic concepts (sigh). The "model" driven development world may provide some of the best ways to attack this. An abstract model representation (aka UML and more likely it's predecessors) holds out hope of being able to generate multiple representations.
|
