Re: Language = Namespace. was: How namespace names might be used

At 4:32 PM -0400 6/21/00, Tim Berners-Lee wrote:
>-----Original Message-----
>From: Tim Bray <tbray@textuality.com>
>Nor do I, because  you don't *FIND* a resource by dereferencing a URI.
>A resource is abstract and what you get back is a bag of bits -
>not the resource but some (possible poor) representation of it.
>
>We are talking HTTP here:
>You don't (despite the http term "GET") really *get* a resource.
>You get a representation of the resource.
>The HTTP request should (i often think) have been called "render"or
>"represent".
>The HTTP request says along the lines of
>(as of ________ and until __________ the URI you asked for identifies
>a resource which can be validly represented in _image/gif_ ____ by
>__34687126472438[...]
>
>
>This doesn't preclude, for example, being told that another file is
>another valid represenbtation of the resource.
>
>That is why, if you dereference a namespace and get an entity body which
>happens to be a schema document, you can use it if it is useful,
>but that isn't the end of the day.  It *is* (for HTTP) information from
>the horse's mouth, so what you know is definitive in that sense.
>But there is no way you can know everything.
>
>That also is why we do *not*  have to define (as some people have worried)
>  before we go forward,  exactly what you will get under
>any circumstances when you derefence a namespace URI.
>We just have to identify it

Not strictly true. Since I can claim that _anything_ is a 
representation of a namespace, even a gif of my (nonexistent) dog, 
there are no operational consequences to claiming retrievability for 
namespace URIs, as there is _nothing_ that I can count on getting 
back. So we can avoid defining this, but then we get no new advantage 
that we didn't already have.

I don't see the merit in a claim that offers no new operational 
capabilities, and simultaneously obscures the point of the namespace 
standard: which is to globally name elements and attributes.

This was decided at least 10 times by the XML working group, and then 
again at least 10 times by the namespaces working group, and I don't 
see that revisiting  the decision to omit any such implications helps 
us forward. rather it casts us back in time to the era when I was 
arguing that we should just not issue a namespace recommendation 
because there was no fundamental agreement as to how it should work.

How far back in time to we need to go? How many already-taken 
decisions on namespaces do we need to reverse to fix this problem.

The philosophy behind namespaces makes fewer assumptions than you do, 
but it does not prevent retrieval of resources based on namespace 
URIs, so I see no reason at all that we should try to change the 
basic architectural decisions of the namespaces group, long after the 
fact.


>  >This seems central to the disagreement.
>>
>>If we agreed that namespace names were just names, then we would have a
>>basis for building a rough consensus.
>
>If by "just names" [identifiers] you could accept all the things which
>come as a result of naming something.
>
>- metadata about a resource
>- being about to look up a representation of a resource
>- people discussing it over coffee
>- and so on
>
>and so on then that would be fine.
>We agree I think that identity is the core.

Those things are possible, but not necessary consequences of namimg 
something. I have an idea in my mind, I call it "Burt". You may never 
be able to retrieve that idea, and that name may be ambiguous between 
hundreds of thousands of people, and the idea in my head, but it's 
been "named" nonetheless. The only properties that it's acquired from 
your list are being able to talk about it over coffee, and it got 
that because I told you the name, not because I assigned it.

Let's have a moratorium on all discussions where the decision doesn't 
clearly change the code that someone can write, either by:

   1. enhancing interoperability by letting some markup have an effect 
on someone else's system without a prior arrangement between the 
system authors,

   2. preventing some kinds of code being written, or markup being 
applied, because of a known problem with that kind of implementation 
or markup.

>An identifier is a hook.  A great big solid hook.
>No more. Just a hook.  Once you have made a hook
>you can't stop it from being used to hang things on.
>
>A namesapce name is a URI. A great big solid URI.
>No more. Just a URI.  Once you have made a URI
>you can't stop it from being used to hang things on.
>
>Using a URI, from the Namespace Spec'd point of view, stops there.
>Anthing else is done by other specs.
>So "just a name" in a sense I would agree with.
>
>But the "just" suggests you want to stop people using it
>for anything. Which you never can.

No more can you _make_ people use for other things. However, if we 
give people the idea that to be useful, namespace names must have 
some kind of definitional resource available, this is a disservice, 
because the goal of namespaces is very limited: unique identification 
and no more.

We can't prevent people from doing what you want, nor force them to 
either, nor does it affect the core utility of the namespaces 
recommendation whether they use URIs the way you want to or not.

So what's the problem?

>  > But clearly some of us don't.
>>If we agreed that they were something more, and had a pretty crisp
>>description of what that was, and that this was more important than the
>>original goal of naming, once again we could move forward.  But some of
>>us either want to stay in the "just-names" space, and others aren't
>>comfortable with "something more" without more details.
>>
>>Inspiration, someone? -Tim [Bray]
>
>I think the whole point of the "hook" analogy is that namespace URIs
>"just names" makes all the other things you can do with them possible.
>
>Tim BL

-- 
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
http://cs-people.bu.edu//dgd/             \  Chief Technical Officer
     Graduate Student no more!              \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
                                              \__________________________

Received on Thursday, 22 June 2000 12:12:57 UTC