[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Low level versioning
Joe, Actually the UN/CEFACT work on BRIM re-dated OASIS CAM - and that started in 1999/2000 ; -) And prior to that the EDI world tried IMPDEF as a means to automate validations. As always - we continue to build in small steps on the shoulders of giants... I'm not sure where all this gets Joe Chiusano (Inc) - but in terms of furthering the human condition on the planet - well then - we all like to think we are slowly improving people's lives somewhere, somehow? To paraphrase - one small step for Joe Chiusano - one even smaller step for mankind?!? I do feel we are continuing to understand the metrics in play here - and why things are the way they are. Cheers, DW -------- Original Message -------- Subject: RE: [ubl-dev] Low level versioning From: "Chiusano Joseph" <chiusano_joseph@bah.com> Date: Wed, May 17, 2006 12:18 pm To: "David RR Webber (XML)" <david@drrw.info> Cc: "UBL-Dev" <ubl-dev@lists.oasis-open.org>, "XML-Dev Mailing list" <xml-dev@lists.xml.org>, "Fraser Goffin" <goffinf@googlemail.com> <Quote> Your suggestion mirrors the approach CAM is using </Quote> Then I claim that I invented CAM in January 2002 ;) Joe P.S. Where does that get me? From: David RR Webber (XML) [mailto:david@drrw.info] Sent: Wed 5/17/2006 11:39 AM To: Chiusano Joseph Cc: UBL-Dev; XML-Dev Mailing list; Fraser Goffin Subject: RE: [ubl-dev] Low level versioning 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]