[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)
Please ignore my comment. I was wrong about UUID. It is based on MAC address, not IP. So you should not have chances for duplicates if MACs are uniques (and they should be!). Btw, there's a link RIM: [UUID] DCE 128 bit Universal Unique Identifier http://www.opengroup.org/onlinepubs/009629399/apdxa.htm#tagcjh_20 Regards, Diego -----Original Message----- From: Matthew MacKenzie [mailto:email@example.com] Sent: Friday, September 26, 2003 2:09 PM To: Diego Ballvé Cc: Duane Nickull; David RR Webber; firstname.lastname@example.org Subject: Re: [regrep] Re: Republica Case Study (Was: Re: [regrep] Web Site update request) Diego, I may be all confused here, but I beleive that you can generate the UUID yourself before submitting. It is just important that the UUID is an actual UUID, and not some approximation thereof. If your UUID were to match something already in the registry, that just wouldn't be very nice. Forgive me if this is just a feature of my company's product and not ebREG :-) Matthew MacKenzie Yellow Dragon Software Corporation http://www.yellowdragonsoft.com/ Diego Ballvé wrote: +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:email@example.com] Sent: Friday, September 26, 2003 4:41 AM To: David RR Webber Cc: Chiusano Joseph; Farrukh Najmi; Kathryn.r.Breininger@boeing.com; firstname.lastname@example.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 <email@example.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 To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.