RE: Proposal for R120 WSDL URI References

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Friday, November 01, 2002 10:36 AM
> To: www-ws-desc@w3.org
> Subject: RE: Proposal for R120 WSDL URI References
> 
> 
> Arthur,
> 
> 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.

Does this mean that a URI representing a namespace name has exactly the
same meaning as when it appears as a link in an HTML document?  OK,
let's not go there...

> I'm not sure what you mean by the WSD WG is checking with the TAG.

We plan to look at TAG findings relating to this issue, is all.

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

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.

> Cheers,
> Dave
> 
> > -----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
> [mailto:www-ws-desc-request@w3.org]On
> > 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 14:47:35 UTC