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

-----Original Message-----
From: David G. Durand <david@dynamicdiagrams.com>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Monday, June 19, 2000 5:50 PM
Subject: 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.


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.

>>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 [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.

XHTML language <h:title> means the cointents is the title (as in english) of
a document,
as defined the XHTML recommendation.
It does not mean the content of the element is the temperature in Honalulu.

The Namespace is a languge, it comprises set of tokens, syntactic
constraints and meaning.

The essential thing is that the same identifier identifies a language.
Because if I can't use the identifier to make statements about the language
and with the language then it doesn't identify the language.

We must for example be able to tie a namespace to a standard
which defines a language. We do, of course, by declaration
in the spec, so it is difficult to imagine a world where we don't.

> 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.

>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.

>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.

What is returned by an HTTP request  I am all for leaving undefined at this
level.

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".



>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


Yes, I do have a few good metadat properties in mind already.
ïs a sublanguage of" and  "is a Micr*scape plugin for"
are a couple.

But using a schema is good too: you can only syntactic things but
at this layer that is all we are talking about!  I would really
hope that xml-schema allows you to lob extra RDF assertions in
to point to or give other details in languages we dream up later.
That was a requirement I expressed on xml-schema.

>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.

>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.


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.

>   -- David


Tim

>_________________________________________
>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 Wednesday, 21 June 2000 16:47:32 UTC