OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [regrep] Issue with UUID's for Core Components and BIE's

My two cents inserted below with "<PM>" tags...

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]

Duane Nickull wrote:

> Apologize for the cross post in advance, but I feel both of these 
> groups need to address this issue.
> The Core Components and Registry specs both mandate a unique 
> identifier to be used in certain places.  IN the registry, it is for 
> every single registry object.  Each Core Component also must have an 
> identifier. 
> In a recent project I did, I decided to use the registry UUID format 
> for the Core Components.  That is the DCE 128 bit algorithm for 
> generating UUID's.  We also demonstrated programmatic access to the 
> registry to retrieve copies of Core Components, slurped them into a 
> context assembly utility along with an XML declaration of the 8 
> context categories and values representing a specific set of contexts, 
> and spat our several BIE's, which were aggregated onto an XML schema.  
> The good news is that all went well and the system works perfect.
> There were some questions however that do need further discussion IMO.
> 1. Should a BIE carry the same UUID as the Core Component it was 
> derived from?

Are they the same object? If so yes. If not not. Sorry I do not know 
whether a registry stores only BIE or does it store CC and BIE? I 
suspect it is the former. In that case same id makes sense.

<PM>I think to be in line with the spirit of the CCTS I think it'd be best to expect both the CC and BIE objects to be stored.  In the CCTS model a qualified BIE is based on the CC, not the unqualified BIE representation of the CC.  True, the unqualified BIE must match the CC completely. Though for those that want to be true to the CCTS model I'd recommend allowing for the storing of CCs, so that BIEs can be associated (in the ebXML registry sense of association) to the CC they are based on.</PM>

> 2. Either in addition to, or alternatively to #1, should a BIE carry 
> its' own unique UUID?  If it is placed into a registry, the UUID will 
> be assigned to it by the registry,

A registry  client *CAN* specify a UUID for a RegistryObject and the 
registry MUST honour it if it is a valid urn:uuid URN.

> but it also need to be serialized inline into the BIE to be used 
> outside of the registry or in places where access to the Registry RIM 
> instance data is not possible. (real world use cases exist for this).
> 3. If the BIE does have to have it's own UUID, possibly in addition to 
> the COre COmponents UUID, should this UUID be in the 128 bit algorithm 
> format OR should it use something akin to the UDEF format that can 
> convey context variables?  This may be crucial to aid business mappers 
> and integration software (rich client applications) to map the BIE to 
> existing data sources.

I think it should be a UUID consistent with id atribute of RegistryObjects.


> Thank you for any comments on this.  I have done it one way but would 
> like to not reply with what I have done until I hear ideas from others 
> since I am not happy with my solution.
> 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]