Re: [regrep] [RS Issue] Allowing non UUID,URN values for RegistryObject.id

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

First a reminder to colleagues of our special meeting at 7AM PT this 
morning to review the XML Schema files.
The files are in the zip file containing the draft-01 distribution under 
the schema folder:

http://www.oasis-open.org/apps/org/workgroup/regrep/download.php/10858/regrep-3.0-draft-01.zip

BEDINI Ivan RD-BIZZ-CAE wrote:

>May be I haven't understand these new feature. My question is:
>Will be able to federate objects with a unique local ID 
>
Yes, since the id of an object in a federation context is the local id 
qualified by the home registries base URL
and since id will be unique within home registry, therefor a 
federatation qualified id will be universally unique.

>or to do a difference with objects with universal ID in a query?
>  
>
a unique id is a unique id so any id comparison will be doable between 
an object with an older style urn:uuid and new arbitrary URN.

BTW please note that I will be updating canonical data to use URNs for 
id attribute values where the URN will likely be same as its current
lid attribute value. This will make identifying canonical objects much 
easier.

*******************************************************
*******************************************************
* This is very tedious work so please speak up if you have an issue.  *
*******************************************************
*******************************************************

Here is an example:

Old:

<SubmitObjectsRequest>
  <rim:RegistryObjectList>
    <rim:ClassificationScheme
      lid="urn:oasis:names:tc:ebxml-regrep:classificationScheme:EmailType"
      id="urn:uuid:09ac70b4-b314-454a-a512-c16cf4430ef6" isInternal="true"
      nodeType="urn:uuid:bd0c092a-cb38-4578-8520-81274054f678">
...
</SubmitObjectsRequest>




New:
<SubmitObjectsRequest>
  <rim:RegistryObjectList>
    <rim:ClassificationScheme
      lid="urn:oasis:names:tc:ebxml-regrep:classificationScheme:EmailType"
      
id="urn:oasis:names:tc:ebxml-regrep:classificationScheme:EmailType" 
isInternal="true"
      nodeType="urn:oasis:names:tc:ebxml-regrep:NodeType:UniqueCode">
...
</SubmitObjectsRequest>

Notice the id attribute value change and the nodeType attribute value 
change. Basically the id attribute value will be changed to be same as 
lid attribute value
in canonical objects and any reference attributes such as nodeType will 
be changed to the lid attribute value of the referenced object. Note 
that this would address Goran's issue of wnating more human friendly 
ways to identify a referenced object.



Thanks.

>Thanks,
>Ivan
>
>
>-----Message d'origine-----
>De : Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] 
>Envoyé : mercredi 26 janvier 2005 02:32
>À : regrep@lists.oasis-open.org
>Objet : Re: [regrep] [RS Issue] Allowing non UUID, URN values for RegistryObject.id
>
>Farrukh Najmi wrote:
>
>  
>
>>Matt commented on regrep-rs-3.0-draft-01.pdf section 5.1.2 where it 
>>says "The id MUST be a Universally Unique Identifier (UUID) and MUST 
>>conform to the format of a URN that specifies a DCE 128 bit UUID as 
>>specified in [UUID]" as follows:
>>
>>"There are certain situations where it may be necessary for a registry 
>>to specify an ID That is not dce 128.  For example, in Adobe's 
>>implementation, all user information comes from our Policy Server, and 
>>it has its own IDs.  we use a namespace to indicate this, e.g.
>>urn:aps:node:87787887878787.  This section should be lenient to this."
>>
>>I have long felt that we should relax the id attribute to allow any 
>>URN and require that the registry check for uniqueness within the 
>>local registry during submission. In a federated situation the local 
>>id is implictly qualified by the home attribute value for the home 
>>registry so that would allow global uniqueness.
>>
>>Does anyone object to the change that allows RegistryObject.id to be 
>>any URN value that is unique within the local registry? If so please 
>>indicate your reasons clearly and indicate whether you could live with 
>>this change if others felt it was needed. Thanks.
>>
>>    
>>
>Here is how the new text on id attribute reads for draft 02:
>
>5.1.2 Unique ID Generation
>
>As specified by [ebRIM], all RegistryObjects MUST have a unique id contained within the value of the id attribute. The id MUST be a valid URN and MUST be unique across all other RegistryObjects in the home registry for the RegistryObject.
>
>A Submitter MAY optionally supply the id attribute for submitted objects. If the Submitter supplies the id and it is a valid URN and does not conflict with the id of an existing RegistryObject within the home registry then the registry MUST honor the Submitter-supplied id value and use it as the value of the id attribute of the object in the registry. If the id is not a valid URN then the registry MUST return an InvalidRequestException. If the id conflicts with the id of an existing RegistryObject within the home registry then the registry MUST return InvalidRequestException for an UpdateObjectsRequest and treat it as an Update action for a SubmitObjectsRequest.
>
>If the client does not supply an id for a submitted object then the registry MUST generate a universally unique id. A registry generated id value MUST conform to the format of a URN that specifies a DCE 128 bit UUID as specified in [UUID]:
>
>(e.g. /urn:uuid:a2345678-1234-1234-123456789012/).
>
>
>
>--
>Regards,
>Farrukh
>
>
>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.
>
>  
>


-- 
Regards,
Farrukh