[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [regrep] Re: [ebxml-cppa] CPP identification revisited
This is a very good discussion. A few points regarding Federation capability and Registry specs follow: 1. Federation capability is not currently defined (normative or otherwise) in the V2.0 specs. 2. Defining a normative Federation capability has been part of our phased delivery matrix (planned work items) since mid 1999. 3. Adding Federation capability as a normative part of the specs is one of the proposed work items for the V3.0 specification. Some thoughts on the UUID etc debate are: -We have a normative UUID capability where UUIDs are globally unique and independent from any federated capability and not meant to be human readable. -We have a normative external id capability where ExternalIdentifiers are potentially human readable -We do not currently have a normative way to assign URNs to a RegistryObject (other than urn:uuid...). This has been discussed in the past. -We could easily add a normative way to assign URNs to a RegistryObject using the existing ExternalIdentifier mechanism in a stylized way. For example we could define that any ExternalId using the scheme URN is a URN. This would be a low cost / high value feature addition and makes sense for us to pursue in V3. To summarize, there are many way to identify and annotate a RegistryObject. Each way has its unique value, purpose and constraints: -UUID for assigning machine readable globally unique keys. Not human readable. -ExternalId for assigning more meaningful names based on well known naming schemes like DUNS -URN for assigning unique names that are human readable. These names require a registering with IANA for the root name space (e.g. oasis) The Federated registry capability should allow the above mechanisms to work across registries in a usable manner. This is an obvious design goal for that work item. -- Regards, Farrukh Christopher Ferris wrote: > Nikola, > > I used the term "authority" in the URI sense[1]: > > <scheme>://<authority><path>?<query> > > I certainly didn't mean to suggest that within "an" ebXML > registry, that the UUID's were a problem, it is only once > they are let out of the bag, so to speak, that they become > meaningless strings of ascii characters. > > As for federation, it isn't clear to me that this is a normative > part of the specs at present. It would be well served to > have the information needed to resolve a foriegn UUID such as > the URI schemes I have suggested might be used in any event > (much more efficient than asking every nearby node if they > know anything about the artifact with the UUID xxxxxxxxxxxxx.!) > > Cheers, > > Chrisd > > Nikola Stojanovic wrote: > > > <Chris> > > The problem with a UUID is that it gives no clue as to what authority > > created it! > > </Chris> > > > > I am not sure why you've introduced "authority" here. Let's say you know who > > I am (even know how "to reach me"). Do you need to know who the "authority" > > that created me was? If yes, why? > > > > BTW, resolvability of UUID in "an" ebXML registry is not (I hope we agree) a > > problem. I would also like to emphasize that "Federated Registries" is (and > > was) one of the candidate working items for ebXML Registry TC so it might be > > useful not to try to map relevant use cases to the current specs. Of course, > > whoever can provide some of those (use cases) would help the team in > > addressing this important functionality. > > > > Nikola Stojanovic > > Lead Technologist, Research and Development > > Encoda Systems, Inc. > > 101 Pineview Terrace > > Ithaca, NY 14850 USA > > nikola.stojanovic@encodasystems.com > > Tel: 607-273-2224 > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC