RE: [uddi-spec] FW: UDDI's UUIDs issue

[Daniel Feygin <feygin@unitspace.com>]

I do not see a contradiction between Paul's and Anne's arguments.  Paul
is talking about resolvability of HTTP URL references to UDDI
information model artifacts residing on HTTP servers, which is
technically fine, although I do not agree with Paul's vision of UDDI as
a backup cache of these things (you can copy files and create mirrors of
repositories without the use of such a highly specialized service as
UDDI).

That does not help if you want to resolve and retrieve a UDDI-resident
information entity by using a URI in a universally acceptable way.  I
see only two sensible approaches of accomplishing that:
1) the specification of a formal HTTP GET interface to UDDI registries
in addition to SOAP - I think this has been previously agreed to not be
the way we wish to go;
2) the specification of a formal uddi: URI scheme that maps to UDDI's
inquiry API.

Please add to this list if you see other possibilities.

I do concede that Paul makes a valid point on the value of UDDI
information model outside of the context of a UDDI registry, where UDDI
API's may not apply.  This substantiates an argument I tried to make at
the FTF that we are unnecessarily constraining what UDDI can be and how
it and its various constituent elements can be applied.  As such
constituent elements I percieve not only the API's and the information
model, but also the design principles and individual elements of design
of the API's (e.g. breakdown of operations, findQualifiers, key bags)
and of the information model (e.g. classifiers, identifiers,
internationalization).  Recent discussion of a taxonomy schema and
taxonomy management API for UDDI also indicates that perhaps UDDI, in
its current form, is not packaged into the best possible form of
deliverables.  Refactoring them might unlock great potential benefiting
the development of other Web information systems, that are interoperable
and intuitive to developers/users.

Daniel


> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net] 
> Sent: Thursday, December 05, 2002 6:23 PM
> To: Uddi-Spec
> Subject: [uddi-spec] FW: UDDI's UUIDs issue
> 
> 
> More discussion on this topic...
> 
> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Paul Prescod
> Sent: Wednesday, December 04, 2002 10:03 PM
> To: Anne Thomas Manes; Munter, Joel D; www-ws-arch@w3.org
> Subject: Re: UDDI's UUIDs issue
> 
> 
> 
> Anne Thomas Manes wrote:
> 
> >  ...
> 
> >
> > I think Paul has proposed that we use an http:// URI rather than 
> > invent a new uddi: scheme to identify a tModel. The point I 
> was making 
> > is that you cannot do an HTTP GET on http://[tmodelname] to 
> retrieve 
> > the tModel details.
> 
> Yes.
> 
> > You have to compose a fairly complicated composed URL (e.g.,
> > http://[server_name]/modelDetails.aspx/[uuid]) as decribed 
> by Karsten 
> > below.
> 
> Just to be clear: Any particular tModel should be fetchable 
> on N different URIs, so there is no single point of failure. 
> The "canonical" URI would be on the website of the 
> organization that invented the tModel. Just as corporations 
> publish WSDLs, they would publish tModels. Just as 
> individuals publish vCards, home pages and FOAFs, they would 
> publish tModels.
> 
> A UDDI registry would become a cache of these tModels. It 
> could be constructed either by spidering the Web (as per 
> Google) or through explicit contributions (as per Yahoo). The 
> contributions service would of course be a web service. To 
> fetch a tModel from its source, you would just do:
> 
> GET http://www.myUUDI_server/mytModel
> 
> Then, to fetch a cached tModel URI, you would do:
> 
http://someUDDI_server/modelDetails.aspx?url=http://www.myUUDI_server/my
tMod
el
http://anotherUDDI_server/modelDetails.aspx?url=http://www.myUUDI_server
/myt
Model

But you would only do this as a backup when the original site was down.
Otherwise why wouldn't you get the information from the horse's mouth?

> If we create a uddi: scheme, I can see the UDDI TC developing a 
> mechanism that would allow you to perform a GET on a uddi: URL and 
> retrieve the resource.

How would it be easier to perform a GET on a "uddi:" URL than on an HTTP
URL? There are already hundreds of toolkits out there that now how to do
the HTTP URL fetch and 0 that know how to do the uddi URL fetch.

  Paul Prescod


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>