[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
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. >>>>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]