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

"Tim Berners-Lee" <timbl@w3.org> wrote:
>So while I can understand the definitions people give of namespaces being
>sets of names which have no relation to particular languages, that does not
>give the W3C or the world what it actually needs to use XML in practice.

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.

>In my opinion we do not have time to hold everything up while we develop
>alternative notions of meaning and of syntactic constraint, with many-one
>mappings and so on,
>when we have to move ahead and much of what has already been done actually
>assumes that the namespace really does include meaning as well as just a set
>of words.

By meaning, I assume you mean some resource capable of producing an 
entity body on request. 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.

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.

You seem to be trying to win a philosophical battle that doesn't need 
to be fought to resolve the practical questions that are creating 
problems. The philosphical question of whether there is something 
"at" a namespace URI is utterly uninteresting from a standards point 
of view until it's grounded in a definition of what information a 
computer program could hope to obtain from that URI. If all we can 
say is that you'll get "some Mime type" and "some data," then 
there's not much point in saying anything.

If we can define a set of useful, extendible metadata properties that 
such a retrieval would return, then the question has practical 
correlates, and it will have practical correlates in people's code. 
[This is what Rick Jelliffe keeps trying to get

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.

The philosophical issue is contentious because some (including me) 
believe that encouraging such behavior is premature and potentially 
harmful. However, it's been possible from the beginning, so it's more 
a matter of economy of wording and concepts that argues against it.

>If so I will be happy to put my weight behind deprocating relative URIs to
>get out of this mess we are in now.

There are details to resolve in a "deprecate" strategy, but 
discussing concrete tradeoffs within a well-defined strategy would be 
a lot more productive.

   -- 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 Monday, 19 June 2000 17:49:50 UTC