[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?) Diego > -----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. > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]