RE: [ubl-dev] Low level versioning

["David RR Webber \(XML\)" <david@drrw.info>]

Steve, 

Belaboring the point here - this is exactly why you want to separate the
versioning off into a layer (aka CAM). 

Notice fault tolerance is a corner stone here with CAM.  There are
version changes you care about, and those you don't.  CAM gives you the
ability to react to those based on the XML instance content directly -
or ignore them. 

As Chin pointed out - the danger when the schema is the versioning layer
is that your parser will reject something for a schema change in a
sub-factor - that you have no interest in and makes no difference to
your system. 

In the CAM approach - you only need to change the CAM template when a
UID item changes that is in one of your templates (and maybe not even -
it can auto-adjust from a registry definition reference!!!). 

Fault tolerance is absolutely essential in making broad versioning and
interoperability work without a exponential cost in terms of support
and maintenance. 

One most obvious touch point for this is codelists and when permitted
value changes.  Do you want your system to fail when new values are
introduced - or adapt automatically?  Your decision will of course
depend on business context - and you want the ability to configure
behaviours depending - some examples - issue error and reject
transaction; issue warning /alert and accept transaction but put in
holding area; automatically update accepted values and proceed; or
ignore data changes - and pass content to downstream processing. 

Good fault tolerance is essential whereas brittle behaviours - just
throw an exception and stop - is counter to the vision of agility and
adaptable XML-driven systems. 

DW 

 -------- Original Message --------
Subject: Re: [ubl-dev] Low level versioning
From: stephen.green@systml.co.uk
Date: Wed, May 17, 2006 12:35 pm
To: ubl-dev@lists.oasis-open.org

My opinion:

I do wonder how useful particulate versioning would be
since there are some inponderables which seem to get
neglected (unless I'm missing something here).

If I version each complex type (in W3C Schema terms) then
add a new element to such a type, properly one would assume
the version number of that type might change. But what if
I do this during a standard re-release: Would all version
identifiers change for the whole schema irrespective of
which complex types have actually changed?

If the answer to that question is yes for some and no for
others, someone is going to get a versioning system which
doesn't match their requirements and maybe they would be
no better than if they had none at all (or worse because they
have to cater for something they don't want and are hindered
in what they do want, let alone the potential for
misunderstanding.

Then it gets worse: If the answer to the question is no - I
only see a change of version ID when a change has occurred
since the previous version - what then happens if a change
is made in the version of something reused within another,
containing complex type but the complex type itself does
not change; should the version ID change?

Again whether you say yes or no, some won't get the type of
versioning they are after and might prefer none at all than
something contrary to what they consider appropriate.

All the best

Steve




Quoting Fraser Goffin <goffinf@googlemail.com>:

> There has been some recent discussion in my organisation as to whether
> there is a need to provide verion information for each
> element/aggregate in our standard data model.
>
> Currently versioning is only visible to implementers on the business
> transaction level schema (namespace), that is, individual parts are
> not individually versioned.
>
> Does UBL provide individual version information for each business
> entity, and are each of these visible when entities are combined to
> form a business transaction ?
>
> I have a feeling that traceability to the core data model needs to
> reflect version, but I remain to be convinced about whether it is
> necessary at this level at run-time.
>
> All opinions welcome.
>
> Fraser.
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing 
> the UBL OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/ubl-dev/
> Committee homepage: http://www.oasis-open.org/committees/ubl/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>
>




---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the
UBL OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/