XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] The <any/> element: bane of security or savior ofversioning?

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS