← Prev in month ← Prev in thread
Next in thread → Next in month →

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

From
Carl Mattocks <>
Date
2005-01-24T19:21:06+00:00
ID
Thread
Re: [regrep] [RS Issue] Allowing non UUID, URN values for RegistryObject.id
+1
< ... id as long as it is unique within the local registry >
carl

<quote who="Farrukh Najmi">
> Anders W. Tell wrote:
>
>> +1,
>>
>> Have the options of working with raw URN is a good relaxation that
>> adds a lot for thoes who work with constructed, generated URN where
>> parts of the URN indicates some or comes from semantical elements.
>
> Since we have not heard any negative opinions on this propose change
> shall I go ahead and relax the spec to allow any URN to be specified for
> id as long as it is unique within the local registry?
>
>>
>> thanks
>> /anders
>>
>>
>> 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.

-- 
Carl Mattocks
co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
co-Chair OASIS Business Centric Methodology TC
CEO CHECKMi
v/f (usa) 908 322 8715
www.CHECKMi.com
Semantically Smart Compendiums
[AOL] IM CarlCHECKMi
← Prev in month ← Prev in thread
Next in thread → Next in month →