Re: [xml-dev] Caution using XML Schema backward- or forward-compatibilit

["Stephen Green" <stephengreenubl@gmail.com>]

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