> The industry standards need to move at a faster pace

 

Agree entirely, however the motivations of some are to constrain change, and concensus is typically hard to acheive. An industry standards body also often finds itself trapped between the competing interests of its members and ... well I could go on, but we all understand the problem.

 

My motivation is to encourage the standards body to allow for private extensions in schemata. There is no reason why a standards body needs or should be in the middle of trading partner agreements which manifest themselves in data exchanges private to those individual organisations. The concern often expressed is that private extension degenerates the standard, but the reality is, without the ability to accomodate change (both breaking an non breaking) and allowing participants to adopt change at a time of their own choosing, then a standard has no future. Natural market pressures will drive adoption. Extensibility (call it forwards/backwards compatibility if you like) is certainly part of the solution, and, as you point out, careful selction of what should be mandatory and optional, and implementation of various validation schemes that support the level of compatibility/tolerance that an individual or pair of trading partners require, and .... well you get the picture.

 

Fraser.

 

On 28/08/07, David Carver <d_a_carver@y...> 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@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php