RE: Updating WSDL Component Designators

Can I add your text to the TAG issue 37 text?  The third draft is at [1].
This seems like belonging to option #11 and the ";" option in #10.  I think
the feedback from Roy on the problems of hiearchical naming conventions
within query parameters applies, whether it's a single parameter (your
proposal) or multiple parameters (as described currently in option 11),

Is there any interest in discussing this at the f2f next week?  I can be
available in person.

As a status update, the TAG did discuss issue 37 extensively at July f2f,
but didn't not make significant process.  I would say that the relationship
between issue 37, rddl, the fragment identifier syntax for rddl, the
relationship between rddl frag-ids and wsdl frag-ids, and metadata in URIs
is quite complicated.  

I don't think that your statement "The heart of the issue is the
inappropriateness of using fragment identifiers in conjunction with abstract
URIs such as namespaces. " is accurate.  It is not clear that frag-ids can
or can't be used with URIs that may or may not be resolvable.  rfc2396bis[2]
talks about what happens if a representation isn't retrieved, section 3.5...

"As with any URI, use of a fragment identifier component does not
   imply that a retrieval action will take place.  A URI with a fragment
   identifier may be used to refer to the secondary resource without any
   implication that the primary resource is accessible. "

This wording has arisen at least in part because of the WSDL WG's
requirements, as well as RDDL and semantic web usages of fragment

I do believe that the issues that arise from fragment identifiers with
namespace names are still valid, I'm just pointing out that I think it is
legal to do so.



> -----Original Message-----
> From: []On
> Behalf Of Jonathan Marsh
> Sent: Monday, September 15, 2003 1:06 PM
> To:
> Subject: Updating WSDL Component Designators
> Appendix C [1] of our spec describes a mechanism for assigning URIs to
> WSDL components using fragment identifiers to combine the
> targetNamespace with an XPointer-like component identifier.  The
> technical problems with this approach were referred to the 
> TAG [2].  The
> heart of the issue is the inappropriateness of using fragment
> identifiers in conjunction with abstract URIs such as namespaces.  By
> abstract I mean URIs without an expectations that dereferencing will
> return a representation of a resource.
> To avoid that problem, I propose using the query component of URI [3]
> instead of fragment identifiers.  The syntax would be:
>   <targetNamespace>?wsdl-<componentName>=<path1>.<path2>.<path3>
> Note that this is not recursive, nor accommodates target 
> namespaces with
> query parameters in it.  If these are desirable, the algorithm could
> look for a query component '?' and if one exists, use ':' as 
> a delimiter
> instead:
> <targetNamespace>;wsdl-<componentName>=<path1>.<path2>.<path3> if the
> targetNamespace does contain a query component.
> Here's what such a proposal would do to the URIs in example C-2 [1]:
> http://airline.wsdl/ticketagent/?wsdl-interface=TicketAgent 
> http://airline.wsdl/ticketagent/?

With the additional recursive functionality, and if the targetNamespace
for some reason was a WSDL Component Designator such as
"http://airline.wsdl/ticketagent/?wsdl-interface=TicketAgent", here's
what you'd get:


And if the targetNamespace already had a query param, like
"http://airline.wsdl/ticketagent?wsdl", you'd get:


I think this mechanism is reversible.  Comments?


Received on Monday, 15 September 2003 17:23:57 UTC