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:

gives as its main reference this:
[XPTR] XPointer Framework. Ed. Paul Grosso et al. 13 Nov 2002. World 
Wide Web Consortium. 25 Mar 2003

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: 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:
>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, 

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.


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

Received on Thursday, 13 October 2005 18:34:00 UTC