RE: [ubl-dev] UIDs RE: [ubl-dev] Low level versioning

[stephen.green@systml.co.uk]

Fraser

Hi. Now we have what appears to be a final answer on this
relating to the UIDs in UBL 2 (I hadn't remembered this)

http://lists.oasis-open.org/archives/ubl/200605/msg00050.html

But there is still room for debate

http://lists.oasis-open.org/archives/ubl/200605/msg00053.html

It seems we will have UIDs for complex types for 'BIEs' in
UBL 2 schemas but we didn't have them in the first public draft.

All the best

Steve



Quoting "David RR Webber (XML)" <david@drrw.info>:

> Steve,
>
> Very good question - and I'm not sure there is a definitive answer -
> here's some ramblings!
>
> Technically you can use the UBL name for the UID - since from the SW
> stance the UID is just a string.
> However - from the human stance - its probably not optimal???
>
> The inverse logic to this is that humans associate sense and meaning to
> words.
>
> Computers of course do not - so  <dfr3l_qwe34>Whatever</dfr3l_qwe34>
> means just as little to a computer as it does to a human!  Conversely
> <myNiceTagName> is just as meaningless as <dfr3l_qwe34> to the
> computer!!
>
> As soon as you start using things that can potentially mean something -
> humans will spend endless hours discussing if that really is an
> appropriate term /use/ meaning et al.
>
> If you just use something like UBL000123 - it defuses this innate
> tendency from the human side (hopefully!) - and of course these can be
> assigned automatically in sequence.
>
> Particularly for things like labelling CPA agreements - where you may
> actually prefer an anonymous label.
>
> Another consideration is - what happens if after much deliberation you
> want to change the names?  If you've used them for the key - there's an
> issue - if you've used a UID for the key - you can freely alter the
> names - and of course do multi-lingual tagnames into payloads - and
> crosswalk via the UID.
>
> Technically though - using english entity names as the UID still works
> just fine - and does save a bunch of assignment exercises thereby!
>
> UIDs are however a lot shorter and hence easier to verify - e.g. "did
> they want me to use UBL001340 in that form or UBL001599?"
>
> Whereas purchaseOrder.entry.builddate as opposed to
> purchaseOrder.entry.createddate is probably more gnarly to
> distinguish...
>
> We also have legacy needs here - no surprise that unlike UBL - alot of
> legacy dictionaries re-use words in different context - so things like
> date and addressline can have the same name - but a whole different
> usage.  Being able to sort this out with a unique ID is definately a
> must - without having to spend too much time on what that label needs
> to be!
>
> Your mileage will obviously vary.
>
> Cynics of course could argue that this is just an attempt to ensure the
> use of a registry to do the reverse lookups on UID values! ; -)
>
> DW
>
> -------- Original Message --------
> Subject: [ubl-dev] UIDs RE: [ubl-dev] Low level versioning
> From: stephen.green@systml.co.uk
> Date: Thu, May 18, 2006 9:56 am
> To: ubl-dev@lists.oasis-open.org
>
> David
>
> Thanks. Might I just ask a couple more things?
>
> If UBL 2 regards the CCTS Dictionary Entry Name as a UID and doesn't
> provide a separate UID, does this couse any problems that you are
> aware of, such as when storing in registries, using CAM, etc?
>
> Related: Can the Dictionary Entry Name be used with CAM instead of
> a typical UID?
>
> Thanks again
>
> Steve
>
>
>
> Quoting "David RR Webber (XML)" <david@drrw.info>:
>
>> Steve,
>>
>> Not exactly - the UID is general tool for unique labelling of entities.
>>
>> Typically in the UBL case - UIDs apply to the actual dictionary entities
>> themselves - so for example a "purchaseOrder.date" would be UBL002345,
>> etc.  Now of course "purchaseOrder.date" could be atomic or an
>> aggregate.  So the UID is an extra column in your spreadsheet that
>> provides those lookup reference values.
>>
>> Similarly if I look at an EDI dictionary you simply re-use the existing
>> EDI element ID value - no need to reinvent codes, and so on for HL7,
>> ACORD, OAGi within those domains.
>>
>> Now as you noted you could assign a UID to a schema itself, and to a CPA
>> instance, BPSS model, and so on - when you insert them into the
>> registry.  This gives you a way to reference that item directly. (Note:
>> in registry there is also a UUID key that automatically gets assigned to
>> any content - but UUID is volatile in the way you indicate - it changes
>> when something gets updated or moved within registry - hence the UID
>> provides the LID - or logical non-volatile lookup key).
>>
>> So to answer your original question - no - UIDs should be static and
>> consist across any registry providing a UBL dictionary and set of
>> schemas.
>>
>> Thanks, DW
>>
>> -------- Original Message --------
>> Subject: RE: [ubl-dev] Low level versioning
>> From: stephen.green@systml.co.uk
>> Date: Thu, May 18, 2006 9:07 am
>> To: ubl-dev@lists.oasis-open.org
>>
>> Hi David
>>
>> Would you mind just clarifying something: the UIDs you mention;
>> are these apportioned to the UBL schemas when they are added to
>> an ebXML registry (and therefore not to be found in the actual
>> standard UBL schemas published on the OASIS website)? If so, does
>> that mean every registry storage of the schemas would probably
>> have different UIDs for the same UBL complex types?
>>
>> Many thanks
>>
>> Steve
>>
>>
>> Quoting "David RR Webber (XML)" <david@drrw.info>:
>>
>>> Steve,
>>>
>>> Thanks for that reference - also in ebXML CCTS we defined simple UID as
>>> alpha character prefix + 6 digit numeric value - e.g. UBL001234,
>>> UBL001291, UBL000119, etc.  These then equate to the "external name"
>>> entity in the ebXML registry RIM when storing things into registry.
>>>
>>> Laterly in V3.0 of Registry there is now the LID - Logical identifier
>>> concept that is linked to this - so you can retain reference to UID
>>> across updates and changes to records inside the registry (LID and UID
>>> are essentially then synonymous within registry).
>>>
>>> In CAM we are also adding an optional version suffix - to allow major /
>>> minor version control as well - i.e.
>>> UBL001291:01:00 and this ties into use registry to store those details
>>> about the vocabulary and semantics.
>>>
>>> This reaches to Frasers' point that this can get gnarly if you have to
>>> UID everything.  Again though - in UBL transactions I'd expect you'd
>>> only UID those things that you want to explicitly use - your SBS - and
>>> / or only those that are deltas from the default UBL usage.  This
>>> obviously greatly reduces the number of items you have to UID.
>>>
>>> And once you have got the UIDs setup - then obviously other people can
>>> snag and reuse your templates.  Then again the UID can be used too to
>>> find examples where your partner is using deltas - via the major/minor
>>> suffix - and so that works as an instant quick search.
>>>
>>> Also - the other purpose of UIDs is to crosswalk between a non-UBL
>>> payload and the UBL standard.
>>>
>>> So I can use non-UBL XML tagnamed payloads - and equate those to the UBL
>>> equivalents.  This approach also aligns well with legacy EDI payloads -
>>> where in EDI the UID is the element dictionary ID code value (both X12
>>> and EDIFACT have these).   This gives people a migration path to UBL
>>> where the ROI is tough to make on converting in-place solutions - at
>>> least they can then claim UBL alignment at the dictionary level if not
>>> the format itself.
>>>
>>> DW
>>>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [ubl-dev] Low level versioning
>>> From: stephen.green@systml.co.uk
>>> Date: Thu, May 18, 2006 3:25 am
>>> To: ubl-dev@lists.oasis-open.org
>>>
>>> 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.
>>>>>