RE: Proposal for R120 WSDL URI References

Jacek,

With all due respect, -1 on this proposed approach. While I agree that the 
XPointer syntax 
is "icky", I'd rather that we not invent something different to solve the 
same problem just because we 
think something is "icky". In all likelihood, tooling will render the 
fragment identifiers invisible
to the developer anywho.

Cheers,


Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Jacek Kopecky wrote on 11/06/2002 05:05:11 PM:

> 
> 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.
> > 
> 
>