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

[Diego Ballv� <diego.ballve@republica.fi>]

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:matt@yellowdragonsoft.com]
Sent: Friday, September 26, 2003 2:09 PM
To: Diego Ballv�
Cc: Duane Nickull; David RR Webber; regrep@lists.oasis-open.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: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.