Re: [regrep-cc-review] Issue #1: Unique Identifiers

["Chiusano Joseph" <chiusano_joseph@bah.com>]

I'll take that in sections:

<Quote1>
I'm wondering about the situations where Core Component work is provided
to a registry after the developers have been
tracking CC IDs without taking into account the potential registry
UUIDs.
</Quote1>

So Core Components have been developed in a development environment that
does not utilize ebXML Registry (a very possible scenario), so there are
no UUIDs assigned. However, each Core Component entity has a more
"human-readable" ID assigned to it. So far, so good...

<Quote2>
The developers will want to retain the CC IDs they are familiar with
during their development work.
</Quote2>

When their Core Component entities are transferred to (or copied to) an
ebXML Registry, they will want to retain these human-readable IDs.

So far, I'm thinking that they can do this by adding a slot to the
RegistryObject class for a human-readable ID for each Core Component
entity. Or, use the ExternalIdentifier attribute.

Also, a 128-bit UUID would be assigned to each Core Component entity
once it is transferred to the ebXML Registry. 

Let's continue...

<Quote3>
If the developers used their own ID scheme for the CCs, then the that ID
gets relegated to the ExternalIdentifier but the UUID still stands as
the CC's ID.
</Quote3>

Regarding "UUID still stands as the CC's ID": It depends on what one
means by "ID", and what "stands as" means. One person may consider the
ID to be the human-readable ID, another may consider the UUID to be the
ID.

<Quote4>
Or would that be too confusing and we should just request that all
developer CC IDs be mapped to ExternalIdentifier?
</Quote4>

I definitely think this is more confusing than it needs to be. We can
request that all developer CC IDs be mapped to ExternalIdentifier, but
the registry will still maintain a UUID by nature.

Here's a reiteration of a quote from the CCTS spec, to help keep us all
(including myself) on track:

p.65: The ebXML Unique Identifier is fully described in the ebXML
Technical Architecture Specification Version 1.04. Its construct is
fully specified in the ebXML Registry Specification 2.0.

Thoughts?

Joe
"MACIAS, Paul" wrote:
> 
> I'm wondering about the situations where Core Component work is provided to a registry after the developers have been tracking CC IDs without taking into account the potential registry UUIDs.  The developers will want to retain the CC IDs they are familiar with during their development work.
> 
> Thinking that through some more I'm not sure that precludes the mapping defining the UUID as the CC's ID.  The developers could still map their internal CC ID to an ExternalIdentifier class.  In practicality it would be a situational mapping. If the development took the registry into account in assigning their CC IDs, then the UUID is likely going to be treated as the ID within the community anyways.  If the developers used their own ID scheme for the CCs, then the that ID gets relegated to the ExternalIdentifier but the UUID still stands as the CC's ID.
> 
> Or would that be too confusing and we should just request that all developer CC IDs be mapped to ExternalIdentifier?
> 
> -Paul
> 
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Friday, August 22, 2003 2:14 PM
> To: Carl Mattocks
> Cc: CCRev
> Subject: Re: [regrep-cc-review] Issue #1: Unique Identifiers
> 
> Thanks Carl.
> 
> Team, please see below for Carl's response to issue #1.
> 
> Joe
> 
> Carl Mattocks wrote:
> >
> > I believe that UUID is sufficient.
> >
> > The use of a Namespace should be enough for  "human-readability"
> >
> > >
> > > ISSUE: Requirement [S1] states that Core Components should have a Unique
> > > Identifier. In our Registry, we already have a 128-bit UUID.
> > >
> > > QUESTION: Will the UUID suffice? Or should this unique identifier be
> > > more "human-readable", for example: "BCC00003" (Basic Core Component
> > > #3).
> >
> > carl
> > Carl Mattocks
> > CEO CHECKMi
> > e-mail: CarlMattocks@checkmi.com
> > *******************************************
> > Business Agent Software that
> > Secures Knowledge for Reputation:Protection
> > *******************************************
> > CHECKMi Compendium the shortcut to Valued & Trusted Knowledge
> > *******************************************
> > www.checkmi.com
> > (usa)1-908-322-8715
> > CarlCheckMi (I M)
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard