W3C home > Mailing lists > Public > www-ws-desc@w3.org > November 2002

RE: Proposal for R120 WSDL URI References

From: Jacek Kopecky <jacek@systinet.com>
Date: 06 Nov 2002 17:05:11 -0500
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: WS Description WG <www-ws-desc@w3.org>
Message-Id: <1036620313.2781.65.camel@localhost.localdomain>

Jonathan, others,

I think I agree with the sentiments against XPointer (quoted below). I'd
like to see how Schema handles this situation because it seems our
problem is pretty much equivalent.

To complete my action item, here are my thoughts on the problem:

I think we might be able to handle this along the lines of the following
simple example:

<wsdl:definitions targetNamespace="http://example.org/"
      xmlns="http://example.org">
  <wsdl:message name="Foo"/>
  <wsdl:portType name="Bar">
    <wsdl:operation name="Foo">
      <wsdl:input name="Foo" message="Foo"/>
    </wsdl:operation>
  </wsdl:portType>
</wsdl:definitions>

The four components defined above would be identified as

http://example.org/message_Foo
http://example.org/portType_Bar
http://example.org/portType_Bar/Foo
http://example.org/portType_Bar/Foo/input_Foo

So basically as in XML/RDF, I'd append the local part to the
targetNamespace, prefixing the potentially ambiguous names with
message_, portType_, binding_, service_, input_, output_, fault_ etc.

What I see as a potential problem with this approach is that the
prefixes above are not namespaced so there's a space for future possible
conflicts here. If we remove 'urn:wsdl:' from Arthur's form, I think it
has the same namespacing problem. (Personally, I don't like the
'urn:wsdl:' part of Arthur's proposal, and AFAICS it is being removed
anyway.)

More generally, the problem is that we have so many things from which we
want to create a single URI:

        1. target namespace of the component
        2. name of the component
        3. possibly parents of the component (applicable on
           <wsdl:input>s, for example)
        4. WSDL namespace
        5. WSDL type of the component

Practically, we could ditch the WSDL namespace and ignore the possible
problems, then my simple proposal and Arthur's xpointer-like (or
xpointer-compliant, I don't know) both work. My approach is rather
simplistic, Arthur's is more formal.

Other approach could be to require that all addressable components (and
I believe all components in WSDL should be addressable) specify unique
IDs (in addition to their names), but this would not be very pretty, and
anyway, IDs are tied to the base URI, not target namespace URI.

I personally don't see any completely correct and yet realistic way to
solve this problem.

Thoughts?

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Fri, 2002-11-01 at 14:47, Jonathan Marsh wrote:
> One of our concerns is that XPointer identifies XML infoitems within an
> XML document.  We are trying to identify abstract components within a
> target namespace.  For instance, definitions for a target namespace
> might be scattered across multiple documents.  It's not even clear
> whether the URI representing the target namespace has a media type, in
> which case it wouldn't have a well-defined fragment syntax either.
> 
> > I did make the suggestion that the issue you raise about complexity of
> > query/path schemes for WSDL might be more architectural and general.
> Was
> > there any sense in the group that this might be the case?
> 
> Yes, I have an action to look at Schema's normalized universal names,
> since they have the same problem with QNames scoped to a particular
> context and residing in overlapping symbol spaces.  The possibilities
> for a more general solution should become clearer as we investigate this
> further.
> 
Received on Wednesday, 6 November 2002 17:05:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:22 GMT