+1 with Duane here.
uid can be kept as a slot, if desired. cc-review should give
the final statement about this.
The only problems with uuid are that:
- it is not as human friendly as CC00001;
- you don't have it before adding it to registry;
To solve the second one, should the RS allow a client
to get a new UUID, generated in the server side???
(IP is also used for UUID generation, isn't it?)
Diego
> -----Original Message-----
> From: Duane Nickull [mailto:]
> Sent: Friday, September 26, 2003 4:41 AM
> To: David RR Webber
> Cc: Chiusano Joseph; Farrukh Najmi; ;
>
> Subject: Re: [regrep] Re: Republica Case Study (Was: Re: [regrep] Web
> Site update request)
>
>
> David:
>
> What is the issue? (not sure if I understand). We are using the
> registry uuid in conjunction with the registry accessor
> information to
> make sure a person can always get back to the exact artifact
> the xml was
> based on. It can resolve at the generate time or subsequently.
>
> The uuid is the same as a uid to me since if you use either
> with a uri t
> specify the exact domain (registry) that the artifact must be unique
> within, there is no problem (assuming that a DCE 128 bit
> algorythm for
> generating a UUID as per the regrep specs will not likely
> generate two
> identical uuid's by co-incidence).
>
> Duane
>
> David RR Webber wrote:
>
> >Duane,
> >
> >Do NOT use the UUID - use a UID instead - and resolve at
> generate time. That
> >way you always get the correct version. CAM approach with
> <ContentReference>
> >is designed to avoid this issue.
> >
> >DW.
> >
> >Quoting Duane Nickull <>:
> >
> >
> >
> >>The work we are currently doing also will likely impact CCRIM et al.
> >>
> >>Some issues:
> >>
> >>A data element in a dictionary has an identifier that uniquely
> >>identifies it within the domain in which is was created.
> The RIM UUID
> >>would duplicate this identifier and supercede it by being a truly
> >>universally unique ID. How to store the Data element in a
> way that when
> >>it is serialized, it takes it's UUID from the RIM instance and is
> >>serialized into the format of the data element (in our case xml)???
> >>
> >>A data element asserts it has a certain status bestowed
> upon it by the
> >>[Responsible ORganization]. That needs to be ina
> serialization of the
> >>data element but cannot conflict with the RIM instance data that
> >>duplicates its' status. How to keep these in alignment?
> >>
> >>A lot more where that came from.
> >>
> >>Duane
