[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 of versioni

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

Re:  The <any/> element: bane of security or savior of versioni
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.

Melvin Chin

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.