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