RE: on "wsdlLocation"


Indeed, the TAG has spent considerable time deliberating providing a human
readable format for namespace name documents in issue 14 [1] .  This format
is called RDDL [2].  This format could be used to contain links to related
resources, such as schemas, stylesheets, wsdl files, etc.  In general, the
TAG has not stated that it believes that namespace name documents should be
human readable, ala RDDL, or machine-oriented such as schema or wsdl.  My
personal assessment is that the TAG is deeply divided about the issue of
whether a ns document SHOULD be human readable, and has settled on "MAY be
human readable" and will provide a human readable format.

IMO, there are at least 2 main use cases for associating wsdl documents
within a namespace:
1) A human decides that they need to write a service to interoperate with an
existing service (or even provide a service).  The human then needs to find
information about the service, including the WSDL.  IMO, this is a clear cut
case of where RDDL would be useful.  The human would dereference the
namespace name in a browser, see the link to the WSDL file and download it.
2) A service interface changes, and machine clients need to know ( or finds
out because of a fault) that the interface has changed.  Humans may or may
not be in the loop.  In this case, the new definition needs to be installed.
Now I see 2 different subcases:
 2a) The service has been designed to use a local copy of the wsdl document.
In this case, dereferencing the rddl document to find the link to the wsdl
document might not be the highest performance solution.  
 2b) the service has been designed to use the remote copy of the wsdl

If I recall, I understood case 2b to be the more common usage of wsdl.  This
is why the namespace name was chosen as the URI, because it is the only name
that is common across the potentially multiple wsdl locations.  Case 2b
seems to need a wsdlLocation type solution, ala schemaLocation.

It seems to me that a combination of providing a RDDL document for the
"discovery" case and a wsdllocation for the "caching" case seem to provide a
good coverage of the space using the existing technologies.  Though there
are some problems with even that: does the wsdlLocation "override" the RDDL
document's specifications?

The thing that I would encourage the wsdl wg to consider is the relationship
between namespace names, whereabouts in the process the human vs machine is
involved, and the location of the wsdl documents.  

I believe that a good part of the rationale for having schemaLocation was
because there was no RDDL format, there was a great deal of pressure to NOT
put documents at namespace name URIs, and schema authors wanted to embed
addresses for URIs in the schema document.  

I'm almost tempted to think that "*Location" is really a shorthand for the
RDDL document, and maybe the web architecture should think through that
general problem a little more clearly. 

As always, or so it seems, this is because of the difference between names
and addresses, and the desire to potentially have multiple addresses resolve
to a single name.  

BTW, the TAG is having discussions about whether to meet during the week of
the technical plenary.  I think it might be a good idea if the TAG and WSDL
were to have a joint meeting to talk about the component designators and
rddl.  I believe WSDL is planning to meet that week.  Your thoughts?



> -----Original Message-----
> From: Jeffrey Schlimmer []
> Sent: Wednesday, October 01, 2003 8:42 PM
> To: David Orchard
> Cc:
> Subject: RE: on "wsdlLocation"
> David, is the TAG reviewing a related issue? --Jeff
> > -----Original Message-----
> > From: 
> [] On
> > Behalf Of Sanjiva Weerawarana
> > Sent: Sunday, September 28, 2003 12:13 AM
> > To:
> > Subject: on "wsdlLocation"
> > 
> > 
> > During the F2F the service ref folks argued in favor of
> > introducing a "wsdlLocation" concept ala XSD's schemaLocation.
> > In a recent IBM internal debate Noah pointed to a section of
> > the XSD spec which apparently says something along the lines
> > of "you may deref the namespace and try to find an XSD":
> > 
> >
> > 
> > There's also a note there saying naiively deref'ing may not
> > be the right thing to do.
> > 
> > I wonder whether we should also do something similar.
> > 
> > Sanjiva.
> > 

Received on Thursday, 2 October 2003 13:19:08 UTC