Re: Request for status dump and issues check

>After absolutizing, you simply have to chop off further processing and say
>"if not equal now, then not equal at all", neglecting things like DNS
>case-blindness, symbolic links, http: and ftp: aliases, and so on.

That can be done, certainly, but it's not really the URI semantics. URIs
only define strong equality; they don't define strong inequality; they can
tell you that "http://www.ibm.com" equals itself, but if you compare it
with "http://198.133.16.99" they say only "we don't know".

Yes, browsers operate on this weak-inequality mode when they change the
color of a link to indicate it has been visited. But that's entirely a
convenience feature; a false negative is relatively harmless. (The user
visits the page again when they didn't have to, says "oops", and backs
out.) If you're using URI recognizability to drive machine processing, the
consequences get more expensive -- consider a search engine which must now
waste time exploring redundant links. And if you're using it to drive
namespace-aware document processing, where the essential goal is to be able
to recognize the namespace/localname combination in order to get a yes/no
"is this one I need to process" test, "I don't know" is not a useful
response.

We can extend those semantics for purposes of namespace identity, and say
"if we aren't certain it's equal, namespaces must treat it as unequal." But
this is arguably a violation of the architectural assumptions behind URIs.
And since the argument for absolutizing is an architectural one...

I could live with it, but I'd like a stronger rationalle.


>No problem.  The absolutizing algorithm (RFC 2396 resolution) starts with
>a base URI and a URI reference and generates an absolute URI *and* a
>fragment identifier.

Is that _pair_ of values then to be considered the identity of the
Namespace under the Absolutize proposal? I may have misunderstood, but I
had thought folks in this camp were saying that the namespace's identity
was to be signified solely by a URI.

______________________________________
Joe Kesselman  / IBM Research

Received on Monday, 5 June 2000 16:12:12 UTC