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

-----Original Message-----
From: Tim Bray <tbray@textuality.com>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Monday, June 19, 2000 7:25 PM
Subject: Re: Language = Namespace. was: How namespace names might be used


>TimBL wrote:
>
> ...some sensible stuff about what a "language" is...
>
>The bad news is that I think it's going to be tough to attain consensus no
>matter how rough as to what a language is or should be.  The good news is
>we probably don't need it.  We can agree that XHTML and SVG are languages
>in any remotely useful sense of the word, and that neither the chair I'm
>sitting on nor the contents of, for example, http://www.salon.com are.


We need to agree that when I identify a namespace in which a document
is written I indirectly define its meaning.  Otherwise we'll have people
senbding invoices across the net and quoting this list as saying there
is no reason to suppose that it really was an invoice despite what the W3C
Rec xml invoices says, because the namespace has no semantic connatations.
I think mostly assume that, but I wanted to make sure.

>Thus it is clear that not all resources are languages.


agreed.

>>- a namespace corresponds to a language.  I know that some don't want this
>>model but honestly without it all work on XML should stop immediately and
be
>>restarted with a proper footing. What is XHTML? a Language! That is
actually
>>what the letter stands for. There is meaning in it.  The meaning is NOT
>>carried by out of band discussion, it is carried in the XHTML
specification.
>
>I don't know what "corresponds to" means.

Sorry!   A namespace *is* a language.

> I know what "provides a
>guaranteed-unique name for" means, and that's what I thought namespaces
were
>for.  I know what "describes the display semantics of" means, and I know
>what "renders onto a wide range of display devices" means, and I know what
>"assigns abstract properties using a 3-tuple based architecture" (ie RDF)
>means.  But I don't know what "corresponds to" means.


A namespace is a language. a namespace is a resource.

(A style sheet could describe the display "semantics" of a namespace
if that is what you mean)

>XHTML is a language.  That language has a namespace,

Yes. I would say simply "That language is a namespace"

> which in my view
>is most usefully put to work as a name to enable software that knows how to
>deal with it to recognize it.


The namespace-name (URI) is put to work in that way.
Others might do other things with it, but you are welcome to consider
that the most useful function for you, and I think for a large class of
applications
that is true.

>>- a namespace is identified by a URI.  (That is, if any resource is
>>identified by URI u, and a namespace is identified by URI u, then that
>>resource *is* that namespace)
>
>So... the resource which is to be found by dereferencing
>   http://www.w3.org/1999/xhtml
>*is* the XHTML namespace.

>I don't understand what that means.

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

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

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.


> 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

Received on Wednesday, 21 June 2000 16:30:52 UTC