• From: Melvin Chin <mc@S...>
• To: XML-Dev <xml-dev@l...>, Thomas Lord <lord@e...>
• Date: Sat, 20 Oct 2007 16:23:17 +0800

At 04:39 PM 2007-10-19 -0700, Thomas Lord wrote:
>.....
>Too late for those systems already failing but the solution
>is to impose a discipline of language versioning.   Let's suppose
>we have a schema that (today) *strictly* defines a language
>X (no "any" foo - no handling of future updates).   Tomorrow,
>someone invents the similarly strict language Y and we
>all realize "X should become Y!".

There's a difference between saying "X should span a set
of X-schemas that are proper elements of Y" and
"X should become Y".  The whole idea is to preserve the
validity of X-instances in the space of Y, which is expected
to be defined in such a way as to be a proper superset of X.

The "problem" comes only when Y misses out on certain
aspects which makes it fail in certain ways to include
certain X-instances as proper elements.  So it is not just a
translation issue.


>To make Y the next version of X, we should be obligated to
>define two transforms:  one that converts X to Y, the other
>for Y to X.

Economically, the need is almost always to convert X-schema
to Y-schema.  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.


>So, the solution is that programs shouldn't simply check
>inputs against a schema, if they want an extensible input
>language.   Rather, programs should first transform inputs
>to a familiar type, then check those, and optionally transform
>outputs to some externally requested type.

It's not yet a solution, but basically deferring the "problem" to
the new intermediary called "a familiar type (AFT)".  One has
to ask how X-schemas associate with elements in AFT, and
how Y-schemas associate with elements in AFT.  The battle
of resolving compatibility then goes into AFT but not going away.




cheers.
Melvin Chin

• Follow-Ups:
  • Re: The <any/> element: bane of security or savior ofversioning?
    • From: Thomas Lord <lord@e...>

• 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: Thomas Lord <lord@e...>