[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)
Matthew MacKenzie wrote: > 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 :-) ebReg allows clients to specify a valid UUID using whatever means they may have to generate it. If the client specified id is not a valid UUID the registry is required to replace it with a valid UUID silently. There is no client API provided by ebReg that allows clients to generate a UUID. That is left to client APIs such as JAXR API ( http://www.jcp.org/jsr/detail/93.jsp ) to provide such features. That is how ebxmlrr provides this functionality to clients. In summary clients can generate UUID before submitting. They just have to do it on their own without any help from the registry. -- Farrukh > > > 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: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 >>>>> >>>>> >> >>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. >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]