[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 Siteupdate request)
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 :-)
Yellow Dragon Software Corporation
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:firstname.lastname@example.org] Sent: Friday, September 26, 2003 4:41 AM To: David RR Webber Cc: Chiusano Joseph; Farrukh Najmi; Kathryn.r.Breininger@boeing.com; email@example.com 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 atgenerate time. Thatway you always get the correct version. CAM approach with<ContentReference>is designed to avoid this issue. DW. Quoting Duane Nickull <firstname.lastname@example.org>: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 UUIDwould duplicate this identifier and supercede it by being a truly universally unique ID. How to store the Data element in away that whenit 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 bestowedupon it by the[Responsible ORganization]. That needs to be inaserialization of thedata 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. DuaneTo 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.