RE: Issue 7 - processing model for SOAP headers

(picking up a thread from a couple of weeks ago)

Tim Ewald writes:

> 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.

I agree completely.  On the other hand, we want to be careful not to 
reason from the converse. 

We agree that seeing a URI used as a namespace name does not in the 
absence of other information suggest that a retrieval is likely to be 
successful.  As you say, the majority are not at the moment.  Given the 
fact that many XML documents are processed in situations where performance 
concerns, lack of reliable access to a network, or security considerations 
make it undesirable to attempt a reference, in such situations it is 
better not to try.  Indeed, one large company reporting years ago to the 
Schema WG experience on retrieving namespace URIs pointed out that in 
certain network implementations, the timeouts involved in a failed 
retrieval can introduce latencies far beyond those of a successful 
retrieval.

The reverse is not true, and that's my point:  the appearance of a URI 
does not strongly suggest non-retrievability.  If additional information 
is available to suggest that the URI is retrievable, then appearance as a 
namespace name in no way reduces the likelihood.  I could make RDF 
statements to indicate that the URI should resolve, or I could just 
establish agreement within a community that particular namespace URIs 
resolve.  For example, I believe it is the case that most if not all 
Namespaces defined for W3C Recommendations do resolve.   When running XML 
software in an environment when such information is available, it is 
reasonable to assume that retrievals will often succeed.

I suspect we agree on most of this.  Sorry for any confusion.

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








"Tim Ewald" <tim@mindreef.com>
01/28/05 03:28 PM
Please respond to tim

 
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     "'Marc Hadley'" <Marc.Hadley@Sun.COM>, <public-ws-addressing@w3.org>, 
<vikasd@yahoo.com>
        Subject:        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 Saturday, 12 February 2005 20:13:13 UTC