RE: simple case of IRIs for Components in WSDL 2.0

Well apparently our goals weren't completely clear.

WSDL defines XPointer-based fragment identifiers so that we can identify
_either_ XML structures (such as elements) within the document, or WSDL
components.  One reason we seem resistant to the shortcut syntax
proposed is that it conflicts with (and therefore would force removal
of) the former capability.

As far as the choice of parenthases by XPointer (though it's none of
WSDL's business, we're just using the Recommended extensibility
mechanism) it's hard to see how you could reasonably expect to use
parens as delimiters when they are legal URI characters.  From RFC2396:

      URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
      fragment      = *uric
      uric          = reserved | unreserved | escaped
      unreserved    = alphanum | mark
      mark          = "-" | "_" | "." | "!" | "~" | "*" | "'" |
                      "(" | ")"

IMO it looks to be about a decade too late to address your objection to
those delimiters.

> -----Original Message-----
> From: Pat Hayes [mailto:phayes@ihmc.us]
> Sent: Thursday, October 13, 2005 11:34 AM
> To: Bijan Parsia
> Cc: public-ws-desc-comments@w3.org; Henry S. Thompson; public-ws-desc-
> comments-request@w3.org; Jonathan Marsh; Arthur Ryman; David Orchard
> Subject: Re: simple case of IRIs for Components in WSDL 2.0
> 
> >
> >Either you didn't read, or you didn't understand, that there is a
> >relevant W3C standard for constructing uri fragments, XPointer. It
> >is extensible, not limited to XML
> 
> See below for comments on that. Your view of XPointer does not seem
> to match its view of itself. I certainly did not read it as a W3C
> recommendation for constructing ALL uri fragments.
> 
> >, and reasonable. These are good reasons for using these URIs. They
> >might not be sufficient reasons to override these other
> >considerations, but brushing them off isn't helpful.
> 
> OK, you are right, I am behind the curve on XPointer. Had I known
> about XPointer earlier, and understood the stultifying effect it was
> likely to have, I would have howled earlier and louder.
> 
> >>>>  or users of these languages can be required to insert whitespace
> >>>>before a lexical-breaking parenthesis. But all such ways
> >>>>introduce artificiality and awkwardness into what is otherwise a
> >>>>very natural and widely used syntactic convention.
> >>>
> >>>One can turn this question around and ask why we are requiring
> >>>people to not use a composible, extensible standard (XPointer).
> >>
> >>Because not everyone who is using URIs is using XML, nor should
> >>they be required to.
> >
> >XPointer is not XML specific, and, in this case, is not being used
> >to identify bits of XML.
> 
> I seem to detect a disconnect here. Your co-authored paper, cited
> below:
> http://www.cognitiveweb.org/publications/server-side-xpointer-extreme-
> markup-2004.html
> 
> gives as its main reference this:
> [XPTR] XPointer Framework. Ed. Paul Grosso et al. 13 Nov 2002. World
> Wide Web Consortium. 25 Mar 2003
> http://www.w3.org/TR/xptr-framework/
> 
> which I had already checked out, and whose first paragraph reads:
> "This specification defines the XML Pointer Language (XPointer)
> Framework, an extensible system for XML addressing that underlies
> additional XPointer scheme specifications. The framework is intended
> to be used as a basis for fragment identifiers for any resource whose
> Internet media type is one of text/xml, application/xml,
> text/xml-external-parsed-entity, or
> application/xml-external-parsed-entity. Other XML-based media types
> are also encouraged to use this framework in defining their own
> fragment identifier languages."
> 
> Is it just me, or do I detect a certain, shall I say, XML orientation
> in that paragraph?  The same document later gives a helpful
> definition:
> 
> "[Definition: XPointer processor ]
> A software component that identifies subresources of an XML resource
> by applying a pointer to it. This specification defines the behavior
> of XPointer processors."
> 
> I draw your attention to the ninth word. Now, my point is: why should
> it be that a standard designed for a particular purpose, should be
> used to decide the design of URIs which may be used for an entirely
> different purpose?
> 
> >One reason to resist (certain sorts of) bare names is that they
> >*are* used (in XPointer) for identify the XML bits. There are two
> >things to identify. The XPointer solution gives a algorithm for
> >constructing identifiers for both.
> >
> >>URIs have an importance that transcends XML syntax requirements.
> >>Seems to me that this whole discussion of XPointer is beside the
> >>point here.
> >
> >That's because you don't understand/have knowledge of XPointer. Here
> >are some references:
> >
> >
> >	http://www.cognitiveweb.org/publications/server-side-xpointer-
> extreme-markup-2004.html
> >	http://www.mindswap.org/papers/swrp-iswc04.pdf
> >
> >We've explored using Xpointer for identifying various aspects of,
> >e.g., OWL documents including the axioms associated with a class (as
> >opposed to the class itself), and so forth.
> >
> >XPointers are extensible, composable, and have some other good
> >features. They are, like URIs, butt ugly, for the most part.
> 
> Ugliness I do not care about. Breaking other parsers in widespread
> use I do care about. I also rather deplore the idea of URI syntax
> being standardized in such a draconian way for a single, limited,
> purpose.
> 
> But OK, I give up. I wish XPointer had not used up what are probably
> the two most useful structure-denoting characters ever invented, but
> it is too late to fix that lousy decision (which is like deciding to
> require that all paper only be used to wipe asses, since paper is so
> good for that purpose.) And more generally there seems to be no way
> to prevent IRI syntax conventions from absorbing unlimited amounts of
> the Unicode space, so the rest of us will have to learn to wrap them
> in syntactic cling-wrap everywhere, or add yet another layer of
> character escaping. Sigh. Now I have to go back and explain to a
> different constituency why my bland confidence that URI/IRI syntax
> was harmless has to be somewhat qualified.
> 
> Pat
> 
> 
> --
> ---------------------------------------------------------------------
> IHMC		(850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.	(850)202 4416   office
> Pensacola			(850)202 4440   fax
> FL 32502			(850)291 0667    cell
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 17 October 2005 22:39:16 UTC