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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: more Re: [ebxml-cppa] A big issue


More on the subject of use of UUID. UDDI also
assigns UUIDs to all registered artifacts. At issue
then is
	"what authority is the source of any given UUID?"

One reason that I favor use of URI for identifier is that
it provides for a specifically identified resource. A UUID
on its own requires further context in order that it be
resolvable/dereferencable, whether via web protocols
or what have you.

Last time I checked, there were no plans for replication
w/r/t the ebXML reg/rep. There was some talk about
federated requests, but I am not sure where that has gone
recently.

Then of course there is also the notion of "private"
registries (ebXML as well as UDDI).

The point that I am trying to drive home here is that
in order for a UUID to be of any use, it needs to be
provided with some context (the authority that issued
it) so as to allow it to be dereferenced.

e.g. as an HTTP GET query

	http://www.example.com/?UUID=BE3D2F08-CEB3-11D3-849F-0050DA1803C0

If it is necessary that the UUID value be usable separately
from the URI itself, then go ahead and add an element/attribute
that can hold the value on its own. Would recommend STRONGLY
that it be qualified with some context (such as the URI of the
authority that assigned it, etc.)

My $0.02,

Chris





bhaugen wrote:

> From: Christopher Ferris 
> 
> 
>>I do feel strongly that a) the registry/repository should
>>provide for URI resolution of artifacts stored within
>>and b) that any runtime retrieval/resolution of
>>artifacts such as the BPSS instance should be accessible
>>via web protocols. 
>>
> 
> I agree, and would prefer that everything in the extended
> ebXML artifact space be accessible via Web protocols
> (and I really mean normal HTTP Get).
> 
> I suspect this proposal has not exactly been
> front-and-center in peoples' minds, though...
> and may take some rethinking here and there
> to accommodate.
> 
> -Bob Haugen
> 
> 
> 
> 




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


Powered by eList eXpress LLC