OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-dev] Low level versioning


On Wed, 17 May 2006, Fraser Goffin wrote:

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

Good news!  UBL 1.0cd2 does have version stored in :

xsd:annotation -> xsd:documentation
     -> ccts:Component -> ccts:Version


Bad news:  UBL's treatment of xsd:annotation seems leaning towards
           non-normative optional.  So while a UBL schema found in
           the "xsd/" sub-directory has it defined, similar schema found 
           the "xsdrt/" (run-time commentless version) is absent.


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

1. For long term upgradability & backward compatibility considerations,
I think it is likely an important piece of information to be
associated with every important type (BBIE, ABIE).  It may be hard
to prove that it is important.  But it may be easier to see the
problem without it (see (2)).

2. If you permit piece-wise type assembly of higher-level schema
documents from basic components, this is almost a must, since
different basic component may be upgraded at different times,
and sometimes by different group of people.

3. Namespace level versioning will hinder backward compatibility
processing for many of those applications which choose to let 
schema validator do most of the filtering (please see the long thread
of discussion on Joseph Chiusano's initial question on string
length restriction).   E.g. if your outermost schema is up-versioned
even though all its internal components are at original version,
its (outermost) namespace is altered, thus causing schema validator
to reject at sight even though it should/would know how to process
internal pieces one component at a time.


>>All opinions welcome.
>>
>>Fraser.

Hope it's not too much....




Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6820-2979
Email: cheekai@SoftML.Net
http://SoftML.Net/





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]