[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Low level versioning
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]