[regrep] Re: [ebxml-cppa] CPP identification revisited

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

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>