Re: [ubl-dev] Low level versioning

["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/
>
>