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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: RE: [regrep] Re: Republica Case Study (Was: Re: [regrep] Web Site update request)

+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?)


> -----Original Message-----
> From: Duane Nickull [mailto:duane@yellowdragonsoft.com]
> Sent: Friday, September 26, 2003 4:41 AM
> To: David RR Webber
> Cc: Chiusano Joseph; Farrukh Najmi; Kathryn.r.Breininger@boeing.com;
> regrep@lists.oasis-open.org
> 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 <duane@yellowdragonsoft.com>:
> >
> >  
> >
> >>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.  
> >>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

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