[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] Summary: Issue with UUID's for Core Components and BIE's
Hello all, I would just add one thing about the uri of CCs, BIEs, or any other registry object that represents some kind of standard component or interface definition (other things could be process references, WSDL prot type references, etc, etc). One of the things I like abut the UDDI spec (and before anyone gets upset, there are lots of things to like about the ebXML RR spec as well - probably more than UDDI) is the concept of key generator domain and external tModel key assignment. This does away completely with the concept of registry generated UUIDs and instead used globally unique identifiers based on the domain of the publishing authority. The publishing authority for a UDDI tModel (or regrep extrinsic object) creates the identifier using their domain name as a prefix and a suffix which is unique within the domain. Furthermore the publisher is assigned the "keyGenerator domain prefix" by the registrar and can only publish objects with identifiers than contain their domain suffix. This way we get: 1 semantically meaningful identifiers 2 Globally unique identifiers 3 Interoperable identifiers (different registries will assign the same ID to the same object) So for CC's & BIE's, I would use a key that is the keygenerator domain of the issuing organization and the CCTS dictionary entry name as the suffix. Eg something like: uri:unece-org:ccts:US_Address.ZIP_PostCode.Text the only problem is that the UNCEFACT folks make use of whitespace in dictionary entry names and so we have to either remove it or replace it the corresponding %<octet> representation. In the example above I have just removed the whitespace. Reagrds, Steve Capell Red Wahoo Pty Ltd +61 410 437854 -----Original Message----- From: Duane Nickull [mailto:dnickull@adobe.com] Sent: Tuesday, 13 April 2004 1:52 AM To: UN/CEFACT Core Component WG; regrep@lists.oasis-open.org; CCRev Subject: [regrep] Summary: Issue with UUID's for Core Components and BIE's Thank you for all the contributions. Here is an attempt to summarize what has been said > > 1. Should a BIE carry the same UUID as the Core Component it was > derived from? The general consensus was "no" since they are two different artifacts. I support this view and had a feeling that is what would be said. > 2. Either in addition to, or alternatively to #1, should a BIE carry > its' own unique UUID? If it is placed into a registry, the UUID will > be assigned to it by the registry, but it also need to be serialized > inline into the BIE to be used outside of the registry or in places > where access to the Registry RIM instance data is not possible. (real > world use cases exist for this). The general consensus was "yes". There is also a use case that the schema that constrains the BIE instance (assuming they are represented in XML) should contain a URI to the registry, along with the UUID and protocol reference. Some of this suggests that a use case exists to have a "Home Registry" concept for a BIE. Lots to ponder. > 3. If the BIE does have to have it's own UUID, possibly in addition to > the Core Components UUID, should this UUID be in the 128 bit algorithm > format OR should it use something akin to the UDEF format that can > convey context variables? This may be crucial to aid business mappers > and integration software (rich client applications) to map the BIE to > existing data sources. The consensus was that the 128 bit UUID algorythm be used for this. Reasons stated were that the 128 bit algorythm both meets the requirements for being unique and is an accepted principle. UDEF is not currently part of ebXML. David RRR Webber was the lone voice is dissention and suggested revisiting the concept of the alpha numeric code values. This invites some more questions. First, should a BIE know about which Core Component it came from. The CCTS specification version 2 of 11 Aug suggests in figure 4.2 that this is a correct assertion. Figure 4.3 also supports the view that a BIE can see the UMM Business Information Entity is came from (Not sure if "came from" is the best term to use here. Perhaps "Derived from"?). I support this sine it is likely that there are several use cases to suuport this requirement. Business modellers will likely want to reconcile BIE's with CC's during iterative business modeling. Those responsible for integrating information or managing instances of information will likely require additional pointers to metadata (this is what makes the CCTS so powereful IMO). These are just two two use cases - I know of more. This will logically mean that the BIE must contain both its own UUID and the UUID of the CC it came from. It may optionally (highly probably in every instance) have to contain the other two critical attributes of the protocol and location to bind to in order to retreive a copy of the CC. Let's assume that we will want a BIE to be able to reference the CC which it was derived from. Should the BIE also know what context value set (as per CCS - 8 context categories) were used to help constrain it? I think the answer should be yes since this would help avoid unnatural proliferation of BIE's. This would place a requirement for a serialization of the context value set in addition to the BIE and CC's themselves. The model is fairly easy to work from and I have taken a crack at it. I think that this wil fall into place fairly easily. Aside from that, I believe personally that the CCTS is now 100% implementable. The methodology has great value for all vertical and horizontal fields. I do not see any major issues that would prevent it from being implemented within an ebXML registry. I will incorporate this thread into the CC-Review work STC of the OASIS RegRep TC. Duane -- Senior Standards Strategist Adobe Systems, Inc. http://www.adobe.com To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup. php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]