Re: [ubl-dev] Low level versioning

[stephen.green@systml.co.uk]

Hi Fraser

I notice UBL 2 prd didn't make use of the Version attributes in the
documentation. Next week UBL might be creating the next set of UBL 2
schemas. The versioning was included in the spreadsheets against
every element in the UBL 2 first public review draft but didn't get
into the schemas. The method used was to increment the version when
a change was made to the element but not when there was a change to
elements included in the complex type of the element. That is; a
change to elements didn't cause a change of version of a containing
element. But where there is a new document then all the upper level
elements in the document have the latest version number. Does this
make sense?

A related matter is: how will changes be released and packaged?
Will a new version be a re-release of all the existing documents
(even if not changed) along with any new documents? Will this apply
to minor as well as major versions? (I guess the major versions will
now depend a lot on what happens with UBL and CEFACT anyway and the
versioning system will likely change with that).

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/
>
>