[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Low level versioning
Just in case anyone is having trouble finding a UID amongst the annotation documentations in UBL, UBL uses ISO 11179 via ISO 15000-5 (CCTS) rules to create 'Dictionary Entry Names' which are there in the documented schemas (those in the 'xsd' directory http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/ rather than the 'xsdrt' dircectory). These are deemed to be suitable (pretty much by definition) as unique identifiers (UIDs) for UBL's complex types. Steve Quoting Fraser Goffin <goffinf@googlemail.com>: > David, > > forgive my ignorance of both CAM and UBL. I'm not sure what a UID is > but for now I'll assume its an identifier for a business entity or > aggreate (or any type which is versionable - single element ?) in UBL > and these UIDs can be associated with processing rule in CAM (template > ?). > > How does a user of a service defined by UBL constructs 'know' what UID > (or version attribute value) to use to assert the version of each type > (in a composite message containing many such particles) that they want > to use. And doesn't this raise the bar somewhat for consumer apps ? > > Does that fact that there many be multi versions of a business > transaction in use concurrently each potentially containing differing > versions of contained types, make this problem any more difficult ? > > Fraser. > > > > On 17/05/06, David RR Webber (XML) <david@drrw.info> wrote: >> Joe, >> >> Your suggestion mirrors the approach CAM is using - in that CAM allows >> you to associate UID values and sub-version those - accordingly >> (sub-versioning is critical BTW - allows notion of "use latest always" >> as well as calling out descreet point items - and ebXML registry >> supports LID for this). >> >> However - no re-assembly from parts is needed - the CAM approach >> overlays directly on existing artefacts - which is a big plus - because >> you can version existing instances and schemas in-situ without having to >> change them or the method(s) you use to complete them. >> >> Likewise the UID references can optionally point to semantic content >> stored in the ebXML registry - either as XSD fragments - or using the >> XML noun semantic storage format devised for this purpose. Or - you >> can use standalone techniques in the template - without needing the >> registry. >> >> Clearly you can also use the registry to directly link UID reference to >> namespace item labelling too - providing means to bridge between both >> needs. This would be a nice way to group UIDs belonging to a ns >> release. >> >> So - essentially the versioning mechanism becomes an overlay layer >> through the use of the CAM template. >> >> Thanks, DW >> >> p.s. BTW - this clears this up for me - I thought you were wanting to >> use the registry to store information about the namespaces - eg a CMS >> function!! That is clearly another very obvious use case... >> >> >> -------- Original Message -------- >> Subject: RE: [ubl-dev] Low level versioning >> From: "Chiusano Joseph" <chiusano_joseph@bah.com> >> Date: Wed, May 17, 2006 11:04 am >> To: "David RR Webber (XML)" <david@drrw.info>, "Fraser Goffin" >> <goffinf@googlemail.com> >> Cc: "UBL-Dev" <ubl-dev@lists.oasis-open.org>, "XML-Dev Mailing list" >> <xml-dev@lists.xml.org> >> >> This seems like an opportune time to mention the "Namespace Manager" >> feature proposal[1] that I sent to the OASIS ebXML Registry TC in >> January 2002 (I try to bring it up about once or twice a year, to remind >> folks that it's still out there;) >> >> With such a feature, one could register in an ebXM Registry >> implementation the namespace that each construct >> (element/attribute/datatype) is associated with, as well as the >> constructs themselves, with an association between constructs and >> namespaces. Then, if a schema were to be constructed (assembled) at >> design time using a UBL schema (perhaps retreived in its entirety, as a >> "blob" so to speak) and custom (non-UBL) constructs, the resulting >> schema can reflect the proper versions of the constructs via their >> namespaces. >> >> I've just set myself an electronic reminder to bring this up again >> sometime, somewhere, this November ;) >> >> Joe >> >> [1] http://xml.coverpages.org/namespaces.html >> (search on "namespace manager", or go right to >> http://lists.oasis-open.org/archives/regrep/200201/msg00061.html to see >> the archived proposal) >> >> Kind Regards, >> Joseph Chiusano >> Associate >> Booz Allen Hamilton >> >> 700 13th St. NW, Suite 1100 >> Washington, DC 20005 >> O: 202-508-6514 >> C: 202-251-0731 >> Visit us online@ http://www.boozallen.com >> >> -----Original Message----- >> From: David RR Webber (XML) [mailto:david@drrw.info] >> Sent: Wednesday, May 17, 2006 10:12 AM >> To: Fraser Goffin >> Cc: UBL-Dev; XML-Dev Mailing list >> Subject: RE: [ubl-dev] Low level versioning >> >> Fraser, >> >> I very much believe versioning is needed to the element/attribute level >> in an operational environment and using OASIS CAM this is very much >> attainable / essential. >> >> Therefore I'd pro-offer - if this is a key business need - then you can >> use CAM templates to overlay this fine level of detail over the base UBL >> schema between you are your partners. >> >> As for UBL itself - since the version only changes periodically - on a >> major release schedule - then the course grained ns approach is probably >> sufficient. >> >> DW >> >> >> >> -------- Original Message -------- >> Subject: [ubl-dev] Low level versioning >> From: "Fraser Goffin" <goffinf@googlemail.com> >> Date: Wed, May 17, 2006 10:00 am >> To: UBL-Dev <ubl-dev@lists.oasis-open.org>, "XML-Dev Mailing list" >> <xml-dev@lists.xml.org> >> >> 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/ >> >> --------------------------------------------------------------------- >> 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]