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

RE: Proposal for R120 WSDL URI References

From: David Orchard <dorchard@bea.com>
Date: Fri, 1 Nov 2002 10:35:50 -0800
To: <www-ws-desc@w3.org>
Message-ID: <026601c281d7$10519910$4e0ba8c0@beasys.com>


Thank you for taking the time to respond.  I look forward to your updated
proposal on the frag identifier.  I admit beforehand that I'm worried about
the sentence "The context in which the URI is used will define its
interprettation (URL vs namespace-URI)" as there's a fair bit of consensus
that URI meaning shouldn't be context sensitive.  But let's deal with that
when the proposal comes out.

I'm not sure what you mean by the WSD WG is checking with the TAG.  I
haven't seen any questions to the TAG on this.  Do you mean to members of
the TAG or the Director?  Or do you mean the WSD WG "will" check with the
TAG and it simply hasn't happened yet?  BTW, I'm pretty comfortable that the
TAG will say yay verily to a new media type.  The TAG certainly wanted XSL
and XENC to register media types.  Heck, I'd probably say you don't need to
check with the TAG, just do it.

I should have been clearer that I support media type registration for
reasons above and beyond the need for fragment identifier schemes.  But
let's decouple the issue of media-type registration from the pointer scheme.

I agree the syntax for xpointer is convoluted.  In fact, I'd say it's
downright "icky".  However, if XPointer is not used, particularly for the
extension elements, it seems that a fair chunk of how xpointer deals with
multiple namespaces will have to be re-invented for extension elements.
There are a number of extensions that are defined for WSDL to be useful for
a real-world service, such as the http, mime and soap bindings.  I'd really
like to see how WSDL will deal with these extensions.  As the WSDL spec is
the creator of these extensions, seems to me like WSD WG needs to do the
work that you correctly assign to the creator.  I think it's crucial to
evaluate any proposal for WSDL fragment identifiers with the extensions
defined in WSDL.  I'm convinced the namespace issue will show up and be a
source of pain.  And the solution is to deal with the problem up front,
rather than provide an incomplete solution.

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?


> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of ryman@ca.ibm.com
> Sent: Thursday, October 31, 2002 2:29 PM
> To: www-ws-desc@w3.org
> Subject: RE: Proposal for R120 WSDL URI References
> David,
> The fragment syntax I proposed is conformant with the
> XPointer Framework.
> That framework reserves all schemes associated with
> application/xml, so in
> order for us to define new schemes, we also need to define a new media
> type, i.e. application/wsdl+xml. The WSD WG is checking with
> the TAG for
> the official position wrt new media types.
> Using raw XPointers is awkward for the reasons described by
> Eric [1], which
> include:
> 1. an application would have to include an XPointer processor
> 2. XPointer syntax is very verbose
> 3. XPointers are not unique (e.g. you could use positional information
> instead of attribute value matching). You would therefore
> have to define a
> canonical form in order to simplify comparing WSDL URI-references.
> Here's a simple example of how verbose XPointer is. Suppose
> portType "a"
> contains operation "b" which has fault "c". The proposed fragement is:
> #fault(a/b/c)
> The XPointer fragment is:
> #xmlns(w=http://schemas.xmlsoap.org/wsdl/) xpointer(//w:portType[@name
> ="a"]/w:operation[@name="b"]/w:fault[@name="c"])
> I claim that this is 1) hard to write and, 2) hard to read.
> Concerning the urn:wsdl: idea, the WSD WG agrees that it is
> not necessary.
> The fragment identifier can be used with the target namespace-URI to
> satisfy R120. I'll post an amended proposal soon. The context
> in which the
> URI is used will define its interprettation (URL vs namespace-URI).
> Concerning the treatment of extensibility elements, the creator of the
> extension should define which ones need to be identifiable via
> URI-references and then define an appropriate XPointer
> scheme, or specify
> that full XPointer must be used. The base WSDL processing rules should
> specify that additional extension schemes are allowed. I
> agree that the
> proposal needs to be clear on how extension schemes are
> defined (e.g. to
> manage scheme names to avoid collisions).
> [1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0082.html
> Arthur Ryman
>                       "David Orchard"
>                       <dorchard@bea.com        To:
> Arthur Ryman/Toronto/IBM@IBMCA, <www-ws-desc@w3.org>
>                       >                        cc:
>                       Sent by:                 Subject:  RE:
> Proposal for R120 WSDL URI References
>                       www-ws-desc-reque
>                       st@w3.org
>                       10/24/2002 06:23
>                       PM
> Arthur et al,
> I'm quite concerned about creating a new urn scheme and a
> media type and a
> media type specific query/path syntax in order to get usable
> identifiers.
> If yet another language has to create a frag id syntax/query
> language and
> identifier syntax, I'd probably like to raise this as TAG
> issue, as there's
> something clearly architecturally wrong.  grumble grumble.
> Could you show syntax on why using URIs with XPointer and/or
> the XPointer
> framework is so broken?
> I agree that the use of http schemed URIs is confusing when
> the intent is
> for identification.  But is foisting a domain name into a URN the best
> solution?  There's been a great deal of discussion on this
> topic at the TAG
> BTW.  I had proposed the use of an id: scheme (and larry
> masinter pointed
> to
> his tdb and duri schemes) that allow us to avoid specifying
> an http scheme
> for non-dereferencable resources.  I had basically given up
> on pushing this
> topic any further at the TAG because of lack of support (how
> many arguments
> does one want?), but this might be a reason for it.
> Is the url to urn mapping intended to be by-directional?  As
> in, can I take
> a wsdl urn and construct a url from it?
> I notice that you didn't show any extensibility elements,
> like soap or http
> bindings.  Are they intended to be addressible?  How does an
> identifier of
> an extensibility element in a different namespace get specified?
> BTW, I was chortling as I thought through the use of the
> "name" attribute.
> All the names in your sample document are intended to be
> unique within each
> elements containment hierarchy.  So I got thinking about the
> way that HTML
> used name attributes instead of id attributes <a name="foo"/>
> and #foo just
> works.  We're almost back to html's use of names instead of
> ids.  If we
> just
> had an identifier type that was relative and a simple bare
> name query that
> understood paths, I think most of your problems would be solved.
> urn:wsdl:http://airline.wsdl/ticketagent/#message(listFlightsR
> equest) ->
> urn:wsdl:http://airline.wsdl/ticketagent/#listFlightsRequest.
>  I do admit
> that you've added types to your queries.
> I'd also like to encourage y'all to think about these problems from an
> overall web architecture perspective.  If the problems you
> are facing seem
> more general than describing web services - like creating
> schemes and media
> types in order to do identifier syntax? - then you might be
> able to punt
> the
> problem somewhere else.  The benefit is that you might have to do less
> work.
> Cheers,
> Dave
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org
> Behalf Of ryman@ca.ibm.com
> Sent: Thursday, October 17, 2002 8:07 AM
> To: www-ws-desc@w3.org
> Subject: Proposal for R120 WSDL URI References
> Here's the proposal: (See attached file: URI-References.html)
> Arthur Ryman
Received on Friday, 1 November 2002 13:47:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:40 UTC