[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The <any/> element: bane of security or savior ofversioni

• From: Thomas Lord <lord@e...>
• To: Melvin Chin <mc@S...>
• Date: Sat, 20 Oct 2007 11:41:07 -0700

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

• References:
  • Re: The <any/> element: bane of security or savior of versioning?
    • From: "Stephen Green" <stephengreenubl@g...>
  • Re: The <any/> element: bane of security or savior of versioning?
    • From: "Stephen Green" <stephengreenubl@g...>
  • Re: The <any/> element: bane of security or savior of versioning?
    • From: noah_mendelsohn@u...
  • Re: The <any/> element: bane of security or savior of versioning?
    • From: Melvin Chin <mc@S...>