Re: [xml-dev] The <any/> element: bane of security or savior ofversioni

[Thomas Lord <lord@emf.net>]

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