RE: Updating WSDL Component Designators

Ah, thanks for the reference, indeed I'm proposing a variation of option
#11.  I'm honored to be in the company of Noah.  I'll add a reference to
the draft TAG finding in the agenda.  I wouldn't bother adding anything
until next week though, after we've shown that my solution is completely
broken (or not).

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Monday, September 15, 2003 2:21 PM
> To: Jonathan Marsh; www-ws-desc@w3.org
> Subject: 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), fwiw.
> 
> 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
> identifiers.
> 
> 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.
> 
> Cheers,
> Dave
> 
> [1] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0054.html
> [2] http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-
> 03.txt
> 
> 
> 
> 
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org
[mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Jonathan Marsh
> > Sent: Monday, September 15, 2003 1:06 PM
> > To: www-ws-desc@w3.org
> > 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/?wsdl-operation=TicketAgent.li
> stFlights
>
http://airline.wsdl/ticketagent/?wsdl-input=TicketAgent.listFlights.list
> FlightsRequest
>
http://airline.wsdl/ticketagent/?wsdl-output=TicketAgent.listFlights.lis
> tFlightsResponse
>
http://airline.wsdl/ticketagent/?wsdl-operation=TicketAgent.reserveFligh
> t
>
http://airline.wsdl/ticketagent/?wsdl-input=TicketAgent.reserveFlight.re
> serveFlightRequest
>
http://airline.wsdl/ticketagent/?wsdl-output=TicketAgent.reserveFlight.r
> eserveFlightResponse
> 
> 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:
> 
>
http://airline.wsdl/ticketagent/?wsdl-interface=TicketAgent;wsdl-input=s
> omething
> 
> And if the targetNamespace already had a query param, like
> "http://airline.wsdl/ticketagent?wsdl", you'd get:
> 
> http://airline.wsdl/ticketagent?wsdl;wsdl-interface=TicketAgent
> 
> I think this mechanism is reversible.  Comments?
> 
> [1]
>
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html#wsdl
> -uri-references
> [2] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0042.html
> [3] http://www.ietf.org/rfc/rfc2396.txt
>

Received on Wednesday, 17 September 2003 16:09:45 UTC