RE: Issue 7 - processing model for SOAP headers

Noah,

My comments are inline...

> What I think you mean:  the appearance of a URI in certain 
> contexts suggests that certain sorts of container processing 
> are unlikely to succeed if the URI won't dereference.  In 
> that sense and in that sense only, an expectation is created.

No, what I mean is that the appearance of a URI in certain contexts suggests
that it won't be dereferencable. In particular, I think many people believe
that the URIs that are used to identify XML namespaces are in the general
case not dereferencable. Clearly there are some that are, but there are many
more that are not. This is especially true with all the schema and WSDL
documents being generated from code on demand by development tools.

I agree that this should not be the case, but I think that many people
simply accept that there's almost no point in trying to dereference a
namespace URI because in most cases it won't work. They simply abandon that
as an approach.
 
> It's a very important distinction, I think.  A key 
> characteristic of the web is that the interactions that you 
> may attempt with a resource are at worst bounded by the 
> scheme appearing in the URI, and sometimes not even by that 
> (e.g. you can use the HTTP protocol to try and get a cached 
> copy of a resource named with the ftp: scheme name, because 
> the HTTP protocol spec says you can). 

I think that if the W3C was willing to make some statement about the meaning
of a namespace URI, this would be more true.
 
> More importantly, the retrievability of a resource can't be 
> changed even by implication when I write the URI down 
> somewhere.  I can take a namespace name and write:
> 
>         <a href="namespaceURI#someFrag">a link</a>
> 
> in my HTML document.   That says something >about the HTML 
> document<, but 
> nothing about the resource at namespaceURI in my opinion.  In 
> particular, it suggests that rendering of the HTML is 
> unlikely to be successful if the URI doesn't resolve. 

I don't think writing the URI down changes it's retrievability. I just think
there is a large set of HTTP URLs that are used as namespace identifiers and
are not dereferencable. I believe that this is so rampant that when I read
an XML document I don't assume that any namespace URL is dereferencable
because most are not. In contrast, when I read an HTML document, I assume
that all HTTP URLs are dereferencable. Again, I'm not saying that this is
the way the world should be, just the way the world is (at least as
perceived by me ;-).
 
> As to whether the URI will resolve, that will depend on the 
> state of the resource, and perhaps other factors such as the 
> health of the network;  it will not in general depend on 
> whether the name is used in a link, as a namespace, etc.  I 
> suspect this is what you meant, but the distinction is very 
> important in ensuring that all web resources are in principle 
> first class, and that the characteristics of a given resource 
> can change over time.

Again, I agree with the theory. However, I think things are trending the
other way. More and more we're using URIs to name things - namespaces,
policy concepts, features, properties, etc. In a lot of cases we're using
URLs instead of URNs. In any case, people are treating those values as
opaque identifiers and the only thing they do with them is compare values to
see if they match. They don't assume anything beyond that.

Thanks,
Tim-

Received on Friday, 28 January 2005 20:28:08 UTC