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] Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange

And if we engage in "avoidance of making things mandatory" for any reason other than enforcing real business data constraints we reduce the value of schema-driven validation.  Doing that requires the applications to do their own structural validation to enforce the business requirements for mandatory-ness which in turn makes implementing changes or assessing the impact of a change even harder. 

Greg

On 12/27/07, Stephen Green <stephengreenubl@gmail.com> wrote:
There are two cautions I am happy with here: 1. That forwards-compatibility
places great constraints on versioning - that these constraints mean a lot
of planning has to go into the earliest version to reduce such constraints,
e.g. avoidance of making things mandatory because they cannot then be
made optional later without breaking forwards-compatibility (in terms of
instance/schema validation). The problem with this seems to be that it is
in these early stages that designers are least likely to foresee such future
requirements for which they must plan. 2. That mistakes made in these
early stages can lead to designers wanting to change semantics to try to
compensate for such mistakes, e.g. because an element wasn't made
optional it cannot be removed and so there is a temptation to change its
semantics - to reuse it for something else rather than remove it. This is
what I believe Roger is warning is not actually any better than breaking
perceived forwards-compatibility. It is just breaking compatibility but hiding
the fact of doing so from the older schema.

> Designing a new version of an XML Schema to be forward-compatible with
> an old version necessitates that the only changes made in the new
> version are "subset" changes, such as:
>
>     - constrain an element's or attribute's datatype
>     - reduce the number of occurrences of an element
>     - eliminate an optional element or attribute
>     - remove an element from a choice
>
> This is very restrictive.  And to what avail?  Answer: to enable
> validation of new XML instance documents against an old XML Schema.
> But as described above, just because data can be validated doesn't mean
> it can be processed.
>


--
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php




[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