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

[Thomas Lord <lord@emf.net>]

Here is my solution to many of the issues raised in this
long thread:

One way to describe the main problem is to say that there's
no good way to write a schema for a language that might
be extended in the future (in fairly arbitrary ways).  We
want to write programs that process the language as it
stands today, but we hope those don't break as the language
changes.   We want to define schema that, when inputs pass,
assure us our programs will do something sensible.  Yet,
these same schema, if they are to handle future formats,
must be so open-ended (e.g., through "any" elements) that
they can make only fairly weak promises.   In practice,
it is observed that the use of open-ended schema leads to
serious numbers of systems failures in million-line systems.

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!".  

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.

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.

With that basic rule, one can begin to define very clean
ways to handle "unrecognized -- from some future version"
fields.   Also, the XML structure of a language is made
orthogonal to the versioning of the language:  different
versions can have completely different strict schema.

-t
http://www.dasht-exp-1a.com