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