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

At 4:48 PM -0400 6/21/00, Tim Berners-Lee wrote:
>-----Original Message-----
>From: David G. Durand <david@dynamicdiagrams.com>
>  >I don't see this at all. It means that one obvious way to use XML in
>>practice leads to confusion at the user and semantic level, because
>>locating resources by means of a URI is a rather different problem
>>from defining a unique name and sticking to it -- the core
>>requirement for namespace processing.
>
>
>Identity is core.  URIs are primarily identifiers.
>It just happens that some URIs have a schem for looking up information
>about them.  The design of that is, as you say, a different problem.
>
>Once you identify something, you allow all sorts of things
>to happen.  You can't shy away from a system of identifeirs
>because you can't say or define now all the things which will
>be done with them.

Who cares what you do with the name. If all you're worried about is 
uniqueness and unambiguity, you don't need to make any claims about 
other things that _could_ maybe be done with the name.

It's just irrelevant whether you can get an entity body from a URI 
used to identify a namespace. Not useless for all tasks, but 
irrelevant for disambiguating element and attribute names.

>  >By meaning, I assume you mean some resource [sic] capable of producing an
>>entity body on request.
>
>Not at all.  By meaning I mean meaning!
>That which is intended to be or actually is expressed or indicated -OED 2nd
>ed.
>
>  Meaning, n. That which is intended to be or actually is expressed or
>indicated.
>Analogy: "Meaning" is name, "noun" a syntactic constraint, and "That which
>is intended to be or actually is expressed or indicated"the meaning.

And what role does this meaning play in the code?

We have several millennia of fierce disagreement as to _every_ core 
issue of meaning. Now I like philosophy, but I don't think we need to 
resolve the disagreements between Wittgenstein and Russell in order 
to define a suite of networking protocols and a data description 
language.

>  > This is something that, in fact, almost
>  >everyone can live without, at least for the near future. Furthermore
>  >nothing in the namespace spec prevents people fetching resources from
>  >absolute URIs today anyway.
>  >
>  >We do have very good arguments that we need more infrastructure
>>before defining a standard result when retrieving from a namespace
>>URI, but that infrastructure is actually pretty minimal: a new
>>Mime-type, to represent a "namespace catalog," and a decision as to
>>what minimum information should be available in that catalog.
>
>
>I think standards here are a good idea.
>I don't think we wait for them.
>And we don't make them exclusive.
>Just as image formats have evolved, so will languages about languages.

I've already responded to this a few times. Without standards, any 
language on this topic is motherhood and apple pie to you, and 
fighting words to others. Since it can't affect the code, without 
tying down the details, we should ignore the issue until we are ready 
to define the details, and thus make some progress on issues that do 
matter.

>  >There have already been several proposals for such things, and they
>>could actually be layered very nicely on top of XML + XLink.
>>
>>
>>>PLEASE can we go ahead on that basis?
>>
>  >I don't believe that there are any practical blockers to doing just that.
>
>Excellent.  We need a process for this list.
>
>The philopshical argume was against the admittedly rather obscre notion
>but one stated here that a namespace name + localname was just a long
>string and had no significance as to the meaning of the document.
>Maybe that idea "died on the vine".

Still seems perfectly adequate for all of my purposes, and all of the 
things that the namespace specification tries to enable.

>  >Without a definition of what namespace retrieval should return,
>>explicitly licensing such retrieval is a NOP -- it allows people to
>>do what they could have done anyway, and it doesn't enable them to do
>  >anything new that they couldn't have done anyway. Furthermore, the
>>language is contentious, so even (especially) if you believe that
>>it's harmless to do such retrieval, it's simpler just to leave it out
>>of the standard.
>
>
>By using a URI you don't license retrieval or unlicense it.
>Like using a hook.

Right. So there's no need to talk about retrieval, since it doesn't 
advance the namespace agenda of identification by a unique string 
with an existing social mechanism to allocate strings without 
conflict.

As I said, retrieval and all the philosophical issues about what a 
namespace URI "denotes" are simply irrelevant to writing systems that 
do useful work.


>  >There are details to resolve in a "deprecate" strategy, but
>>discussing concrete tradeoffs within a well-defined strategy would be
>>a lot more productive.
>
>
>You mean geteing the "namespace are resources"stuff straight first
>rather than deprecating relative URIs as an interim holding step?
>There is a lot of urgency afoot for something to move forward with,
>even if it means a dog-leg later.

No, I mean deprecating relative references, needs to be done at once. 
Preferably they should also be forbidden in a new version of the 
standard issued immediately, so that the syntax can be reintroduced 
once there's at least one interoperable thing that can be done with 
them.

The namespaces as resource stuff is a rat-hole that we can continue 
to explore for months or years if we want to. After all, there's no 
commonly accepted meaning for "meaning", after several millennia of 
recorded debate. So we should be able to get at least another century 
of debate about the "meaning" of namespaces _per se_. Of course, if 
we stick to effective behaviors that are interoperable, or enable 
interoperability, then we have a lot more constraints on the universe 
of discourse, and we might actually get an answer.

    -- David
-- 
_________________________________________
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 15:10:12 UTC