[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]