Re: [xml-dev] Backward and forward compatible schemas ... Relax NG --> Y

["Fraser Goffin" <goffinf@googlemail.com>]

> If the industry standard organization took that approach, it might encourage users to

> contribute their changes back to the organizations that maintain the standards.
 

Yes indeed, something I've been trying hard to encourage, partly to address the 'lack of control' concern that the standards body and some contributors have when faced with requests from organisations who want/need more frequent changes.

 

The motivations of most particpant organisations is in supporting the standard rather than subverting it. So, although I do advocate the inclusion of private extensibility, I also strongly support public extensibility (for use by the vocabulary owner) and the periodic synchronisation of private extensions back into the main public standard where the community as a whole benefits. Of course contributors are very often competitors, so there will always be some timing issues, but by and large these are solvable. It reminds me of the old mantra '... we'll agree on the standards, but compete on the implementation', and is a point of view which IMO nicely sums up what grown ups do in a market-place. Of course there is always the 'Wall Mart' alternative approach :-)

 

Fraser.

On 28/08/07, David Carver <d_a_carver@yahoo.com> wrote:

Costello, Roger L. wrote:
> Hi Folks,
>
> I am trying to characterize the types of changes to schemas which
> enable backward and forward compatibility.
>
I even RelaxNG I tend to only think of these things as being in Forwards
compatibility.  Backwards compatibility can be maintained if items are
optional.   Meaning from my stand point, regardless of what schema
language you use XSD, RNG, SchemaTron, or whatever, it's only backwards
compatibile if you generate an instance that the older version of the
schema understands.

Forwards compatibility is of a more important issue to me when evolving
a data model of any type.  Meaning that the instances created in an
older version should still be valid in a newer data model.    Java is a
pretty good example in this case, APIs mostly used in JAVA written for
1.1, 1.2, 1.3, 1.4...can still run on a JAVA 5 run time without
change.   However, JAVA 5 that uses JAVA 5 specific constructs doesn't
necessarily run on a prior version of the runtime.

Maintaining forward compatibility is key is an Industry Standard schema,
as it allows trading partners to exchange information without the older
implementation necessarily having to upgrade.  They only need to upgrade
when newer fields need to be there.

The key here is keeping an eye on what you make required and as was
stated before what is changed on the occurrence front.  As for the other
comments regarding industry standard schemas, part of the problem with
industry standard schemas is that they take too long to reach the public
again, by that time most business requirements have changed.   The
industry standards need to move at a faster pace and take a page from
some of the more agile approaches to development to start releasing
milestone and release candidates instead of waiting every 3 years to get
a standard out.   If the industry standard organization took that
approach, it might encourage users to contribute their changes back to
the organizations that maintain the standards.





_______________________________________________________________________

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