W3C home > Mailing lists > Public > www-tag@w3.org > September 2005

Re: [Fwd: simple case of IRIs for Components in WSDL 2.0] (abstractComponentRefs-37 )

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 13 Sep 2005 02:05:47 -0400
To: Dan Connolly <connolly@w3.org>
Cc: www-tag@w3.org
Message-ID: <OFC46CB14C.B78F0FBC-ON8525707A.007FC826-8525707B.00217EB1@lotus.com>

Dan Connolly wrote:

> Then we should be able to use  
http://www.w3.org/2005/08/sparql-protocol-query#SparqlQuery

At the risk of putting salt into a still-open wound:  I think the TAG as a 
whole is still, as of Basel, officially unresolved on whether there's a 
preference for / or # in naming sub-resources.   Yes, our progress on 
httpRange14 may take some pressure off, but I don't think we ever went 
backi to / vs. # in particular, did we? Pending such resolution, is there 
a reason that the above is to be recommended over 
http://www.w3.org/2005/08/sparql-protocol-query/SparqlQuery ?   I'm not 
arguing that one or the other is better, just that if we left the choice 
pending for reasources in general, I'm curious why we would take an 
earlier stand on namespaces in particular.  Both of the above look 
plausible to me. 

For that matter, is it obvious that in all cases 
http://www.w3.org/2005/08/sparql-protocol-query?name='SparqlQuery'
is a mistake?  I certainly wouldn't push for this as good practice in most 
cases, but I can't see why it's provably a mistake either.   What am I 
missing? Thanks.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Dan Connolly <connolly@w3.org>
Sent by: www-tag-request@w3.org
09/09/2005 04:23 PM
 
        To:     www-tag@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        [Fwd: simple case of IRIs for Components in WSDL 
2.0]    (abstractComponentRefs-37 )


I think there was some support for this position when we last
discussed abstractComponentRefs-37, but I don't think we
made any decisions.

So I just sent my personal view on how WSDL should map qnames to
URIs.

Anybody agree? Disagree?

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

----- Message from Dan Connolly <connolly@w3.org> on Fri, 09 Sep 2005 
15:18:49 -0500 -----
To:
public-ws-desc-comments@w3.org
cc:
Bijan Parsia <bparsia@isr.umd.edu>, "Henry S. Thompson" <ht@inf.ed.ac.uk>
Subject:
simple case of IRIs for Components in WSDL 2.0
Regarding...

  C. IRI References for WSDL 2.0 Components
  http://www.w3.org/TR/2005/WD-wsdl20-20050803/#wsdl-iri-references

Those URIs are much more complicated than they need to be:

http://example.org/TicketAgent.wsdl20#xmlns(xsTicketAgent=http://example.org/TicketAgent.xsd)

        wsdl.elementDeclaration(xsTicketAgent:listFlightsRequest) 

In the simple case, if there's only one component named CN in
a namespace TNS, then TNS#CN should be a standard URI for it.

e.g. given
 targetNamespace="http://www.w3.org/2005/08/sparql-protocol-query"

and

 <interface name="SparqlQuery"

Then we should be able to use
 http://www.w3.org/2005/08/sparql-protocol-query#SparqlQuery

to refer to that interface.

FYI, I think Henry made this argument in the TAG
regarding issue abstractComponentRefs-37

  http://www.w3.org/2001/tag/issues.html?type=1#abstractComponentRefs-37

... for example at our june meeting.
  http://www.w3.org/2001/tag/2005/06/14-16-minutes.html#item031


Henry should get only credit, not blame, in case I'm misrepresenting
his position.


See also similar comments on XML Schema component designators...

simple barenames for schema component designators  31 Mar 2005
http://www.w3.org/2002/02/mid/1112297140.32006.540.camel@localhost;list=www-xml-schema-comments



p.s. thanks to Bijan for helping me find the relevant part of the spec
in IRC discussion
 http://www.ilrt.bris.ac.uk/discovery/chatlogs/swig/2005-09-09#T19-51-41

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Tuesday, 13 September 2005 06:06:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:36 GMT