Melvin Chin wrote:
>
> Economically, the need is almost always to convert X-schema
> to Y-schema.
But I'm responding to the scenario another poster
offered earlier up. That person has a million lines of
legacy code that uses X and the Y to X morphism
is very important to keeping that system running while
making upgrades incrementally.
> If, by definition, a reverse-relation is necessary,
> then that definition almost for sure imposes excessive
> overhead that is not needed in practice. Furthermore, since
> Y is expected to be an "improved version" of X, it would
> contain extra features which permit elements not recognizable
> in X. Such reverse translation of Y to X must fail by implication.
>
Well, no, not really. It depends entirely on how well designed
X is.
My transform-based approach tells you generally how to
avoid/solve problems like this, but yes, you must *still*
design X with extensions in mind. It's just that future
formats should be transformable into X extensions, not
that they necessarily have to be represented as X extensions.
That's why it's "too late" for systems already suffering
this problem -- you have to design X with extensibility
in mind in the first place, it's just that designing such an X
is simplified if you think of type conversions rather than
simply sub-types and super-types.
-t
