RE: Documents, Cars, Hills, and Valleys

Joshua Allen wrote,
> Miles Sabin wrote,
> > http://news.bbc.co.uk/ refers, not to a document, but to "Todays 
> > news from the BBC", IOW they "see through" the protocol and the 
> > document
>
> Not true.  Every user that actually is forced to use a URL is quite
> aware that they are getting "a web page".  This is exactly the 
> language that people use to talk about what they are doing when they 
> type a URL into their browser's location bar.  Ask any person off 
> the street, "if you type in something like http://blah into a web 
> browser, what do you get back?"  They will tell you "a web page".  
> Then ask them, "If I type http://www.news.com, do I get back a web 
> page with the news on it?" they will say "yes".

OK, this is a straightforward empirical question (ie. we aren't
likely to resolve this issue without going out and doing a survey, but
we could do that and get an answer) so in the absence of evidence
it's really not worth discussing any further. For all that, my
intuitions run counter to yours. People are used to "seeing through"
other media (telephones, televisions, telescopes) and I see no
particular reason (other than comparative unfamiliarity) why the web
should be any different.

> Users are not so stupid or mystified as you seem to be implying.

That wasn't at all what I meant. I think they're _right_ to treat
http://news.bbc.co.uk as referring to todays news from the BBC. They'd 
also be right to treat it as referring to an HTML document.

Here's another analogy. If I show you a photograph of the Eiffel
Tower and ask you "What's that?", then I think that either of these
two answers would be acceptable,

* It's the Eiffel Tower.

* It's a photograph of the Eiffel Tower.

because without additional contextual information the identifier I
used in my question ("that" and pointing) is ambiguous. That
additional contextual information might or might not be present: if
we'd been having a conversation about architecture, then the first
answer would be the most appropriate; OTOH, if we'd been having a
conversation about the merits of photo-realism in 20th century
painting, then the second might well be the most appropriate.

Much the same goes for todays news vs. a document. Except that
typical users are far more interested in the news than they are in
HTML, so in all likelihood the implicit context is one which would
resolve any ambiguity in the URI in favour of the news rather than
the document.

> > Insofar as meaning is determined by use this implies that in the
> > general user community URIs, http: or otherwise, typically don't
> > identify documents.
>
> You are confusing only yourself.  The fact that language can be
> deconstructed and ambiguities can be artificially introduced is no
> excuse for abandoning clarity.

I don't believe that I'm introducing any ambiguity which isn't already
there. The fact that quasi-formal unambiguous definitions can be 
introduced at will is no excuse for abandoning realism ;-)

> > For that matter, what about the XML developer community? As things
> > stand a namespace URI refers to an abstract (ie. non-retrievable)
> > resource rather than any particular document. IMO many of the 
> > problems
>
> This is a totally orthogonal issue.

That's one of the points under discussion. I'm claiming that this is
precisely the same issue in a different guise, and that thinking
about it in these terms is helpful.

> A namespace URI is a unique name, period.  Until you need to make 
> statements about a namespace or dereference a namespace, then you 
> don't need something that identifies "the namespace".

I'm afraid I can't see any way of making these two sentences 
consistent with each other. If a namespace URI is merely a unique
identifier (ie. with no implication of there being any abstact
namespace resource so identified) then there's nothing you could
possibly make statements about. OTOH, if there is something you could
make statements about, then a namespace URI isn't merely a unique
identifier.

> > we've had with the interpretation of namespace URIs boils down to
> > trying to square the circle of having a supposedly unambiguous URI
> > refer simultaneously to two or more distinct resources.
>
> No, I disagree.  The namespace URL in an XML doc is not being
> "interpreted" as referring to any resource.  Maybe *you* think of it
> that way, but the software just treats it as a unique name.

Umm ... in namespace processing the software treats it as an 
identifier of a namespace, surely. That's no more (and no less)
problematic than software treating a bunch of bits as an integer.

Cheers,


Miles

Received on Thursday, 11 April 2002 05:26:19 UTC