OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Am I correct in interpreting this to imply, "Thou shalt use UUIDs as CC
IDs, or thou is not in compliance with CCTS."?

I say yes, you are correct. But what makes most sense for us? I would
suggest that we consider using the UUID as the Unique Identifier (as the
CCTS spec mentions), and that users MAY (using RFC 2119 here) also use
an ExternalIdentifier. What do you think?

Alternatively, we may elect to not stipulate the use of an
ExternalIdentifier since it is described in our ebRIM for this very
purpose. We might want to be careful about redundancy beween our
Technical Note and our Registry specs.


"MACIAS, Paul" wrote:
> Comments inserted as "<PM>...</PM>" below.
> -----Original Message-----
> 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...
> <PM>Yup.  That's it.</PM>
> <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.
> <PM>Agreed</PM>
> 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.
> <PM>True. That's probably at the heart of why it could be confusing to have both a registry UUID and an altrnative ID. It can lead to bad habits to treating the IDs as interchangable.  Still, I think it's only practical to assume that communities will request guidance in where to map the IDs they have been using for traking outside the registry. </PM>
> <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.
> <PM>If we assume it to be reasonable for developers to assign IDs that are not compatible with registry UUIDs, then I do like this solution.</PM>
> 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?
> <PM>However, thinking about this I wonder if by definition we can discount developers from using non UUIDs.  Am I correct in interpreting this to imply, "Thou shalt use UUIDs as CC IDs, or thou is not in compliance with CCTS."?  If so, then maybe the technical note's support for alternative CC IDs (i.e. non-UUIDs) would be an optional mapping, but not the expected case. </PM>
> Joe
> <snip>
tel;work:(703) 902-6923
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
title:Senior Consultant
fn:Joseph M. Chiusano

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]