RE: simple case of IRIs for Components in WSDL 2.0

Dan,

 

I won't track your reply as "accepting our resolution", but neither does
it seem to be a "not accepted either".  I'd appreciate it if you'd
continue to cogitate on this and give us a clearer answer.

 

>From here on down is my 2 cents without my chair hat on.

 

The main root of the problem appears to be that the abbreviated syntax
for RDF URI References in the RDF/XML Syntax Specification is
incompatible with arbitrary fragment identifiers, including the full and
appropriate use of XPointer.  As both specs are W3C Recommendations
there are several ways to view the conflict.  My preferred viewpoint is
that since XPointer was recommended a year earlier than RDF, the latter
bears some responsibility for the incompatibility.

 

The abbreviated syntax only accommodates references where the fragment
is a so-called "barename" identifier, as a result of using an NCName
type attribute as a pseudo relative URI reference.  This effectively
profiles the types of URIs for which abbreviations can be constructed.
Specifically, this shortcut does not accommodate fragment identifiers in
a general way, either by mistake or by design.  If by mistake, it's
clearly an RDF problem.  If by design, the existence of this
abbreviation mechanism must surely indicate that the designers
recognized the advantages of a syntax that was not fully general.  The
tradeoffs between simplicity and generality must have been carefully
considered.  The existence of items that don't fit into the simplified
set is insufficient to warrant a broad effort to severely profile the
form of URIs in general, including those using fragment syntax as
introduced in the XPointer recommendation.

 

I think the reasons WSDL 2.0 component designators benefit from XPointer
compatibility are fairly obvious so I won't repeat them here.

 

Separately, the "no" datapoint below calls into question the aesthetic
decisions in XPointer and even XML itself.  I don't find it productive
to revisit those decisions in the context of WSDL.

 

It seems to me the WSDL WG was asked to produce component designators
for the benefit of SW technologies, but your comment raises doubt that
the fully general form of those identifiers meets the needs of those
customers.  Perhaps a convention for component designators more to the
liking of the SW should be developed in-house, along with whatever
profiles of WSDL that are needed to support them.  Should that be the
judgement of the community, I personally would not object to the
wholesale removal of component designators and the fragment syntax from
WSDL 2.0.

 

________________________________

From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Tuesday, October 11, 2005 3:34 PM
To: Dan Connolly
Cc: Bijan Parsia; David Orchard; Henry S. Thompson; Jonathan Marsh; Pat
Hayes; public-ws-desc-comments@w3.org;
public-ws-desc-comments-request@w3.org
Subject: RE: simple case of IRIs for Components in WSDL 2.0

 


Dan/Pat, 

I think there is a misundertanding somewhere (either me or Pat). 

Pat seems to think there is a trailing closing paren without a previous
matching open paren. Pat wrote: 

So, a trailing close parenthesis 
without a matching open parenthesis is liable to trigger all kinds of 
lexical errors. 

That is not a problem in the XPointer framework since all the parens are
balanced. The WSDL URI have balanced parens. 


Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca 



Dan Connolly <connolly@w3.org> 
Sent by: public-ws-desc-comments-request@w3.org 

10/11/2005 12:58 PM 

To

Jonathan Marsh <jmarsh@microsoft.com> 

cc

Pat Hayes <phayes@ihmc.us>, Bijan Parsia <bparsia@isr.umd.edu>, David
Orchard <dorchard@bea.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>,
public-ws-desc-comments@w3.org 

Subject

RE: simple case of IRIs for Components in WSDL 2.0

 

 

 





On Wed, 2005-10-05 at 13:52 -0700, Jonathan Marsh wrote:
> Thanks for your comment.  The WS Description Working Group tracked
> this as a Last Call comment LC335 [1]. 
> [1] http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC335
>  The Working Group was unable to find consensus that the shorter form
> of component designators would have all the desired characteristics
> that led us to the current design. The issue was therefore closed
> without action.
>  
> We hope that some of the discussion on this list (particularly using
> the best-case scenario rather than the worst-case) alleviates some of
> your concerns.

Some of them.

> 
> If we don't hear otherwise within two weeks, we will assume this
> satisfies your concern.

I asked around if some nearby folks were satisfied.

ok if URIs for SPARQL interface etc. ends with paren?

http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0023.html


I got one clear 'no' answer (below). I'm still thinking about whether
I find the ... #wsdl.interface(SparqlQuery) syntax acceptable.

Pat Hayes writes:
> The problem is that enclosing parens are (pretty much by definition 
> of 'paren')  widely used as textual breaking symbols in lexical 
> analysis. This is true for NL text in almost all human languages, 
> mathematical texts, any LISP-based programming language text, almost 
> all logical notations, etc. etc.. So, a trailing close parenthesis 
> without a matching open parenthesis is liable to trigger all kinds of 
> lexical errors. It is also, for a similar reason, liable to be 
> mis-read by a human reader. (I myself find that I see the close 
> paren, become conscious of the cognitive dissonance, and then have to 
> visually search for the matching open paren inside the string, which 
> is not a natural way of reading and intrudes on what ought to be an 
> unconscious process. This is a psychological hall-mark of a bad 
> visual design, eg see Don Norman's writings.) And there seems to be 
> no need to do this brain-damaged thing, since one could adopt a 
> variety of linking conventions within white-space-free text to 
> achieve the same intuitive-communication purpose, e.g.
> 
>
http://www.w3.org/2005/08/sparql-protocol-query/#wsdl.interface_SparqlQu
ery
>
http://www.w3.org/2005/08/sparql-protocol-query/#wsdl.interface.SparqlQu
ery
>
http://www.w3.org/2005/08/sparql-protocol-query/#wsdl.interface-SparqlQu
ery
>
http://www.w3.org/2005/08/sparql-protocol-query/#wsdl-interface-SparqlQu
ery
>
http://www.w3.org/2005/08/sparql-protocol-query/#wsdl.interfaceSparqlQue
ry
> 
> any of which would be readable and lexically harmless.
> 
> I would remark more generally that there is a tendency which might be 
> called glyph-creep, whereby W3C standards implicitly use up symbols 
> that already have a significant use in the world in general, thereby 
> forcing people to use unreadable work-arounds. XML's seizure of the 
> less-than sign and the ampersand is probably the most egregious 
> example, requiring almost every mathematical text written since 1300 
> to be re-drafted. Please, do not also take away the parentheses.
> 
> Pat

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