Another look at namespaces

[Tim Berners-Lee]

-----Original Message-----
From: Rick Jelliffe <ricko at allette.com.au>

>The only information that properly belongs in a namespace is a list of
>names.


That is not useful.  I realize that the word "Namespace" (as the end result
fo the discussions of modules or docuemnt types or vocabularies  or...)
may be an english word which does not convey this, but a
a namespaces is a language: a set of names plus a set of syntactic
constraints plus - to be useful - a meaning shared by writer and recipient.

That meaning can be to a certian  (and, with technology, growing)
extend by expressed formally in a mapping to other languages.
Or is can be disccussed in the bar,  a mid: URI written on the
back of napkin, and used from then on by the people who were
in the bar in the messages they write to each other.

>All other information, however convenient, is not namespace information
>but something else: what is this "intent" business? There is no mention
>of
>"intent" in the namespaces spec that I recall, quite the opposite.  The
>fundamental justification for namespace is to be free from intent.


The generic Namepsaces draft only indicates how to identify names in a
document
by a URI of a namespace.  It doesn't say anything about the meaning of any
namespace  because it is not that spec which allows one to talk about it.
However, the namespace URI is the hookto which the whole of the rest of the
system can be attached: it allows one in a schema or other document to say
what the names "mean" for any particular level of "meaning".


>There is no W3C method to define  a namespace as list of names.

There is an xml-schema spec in the works destined to do that
and more.

One can either take the existing specs at face value at any point in
history,
and not complain about the lack of functionality.  Or you can work with
the model which you forsee you can

>There is no
>W3C method to declare which schema should be used, akin to the
>stylesheet declaration.

Yes there is: resolution of the schema URI.

>In the absense of these, of course people will
>try to
>turn namespaces URIs into schema declaration URLS.

"URL"  is a term some use to refer to a subset of URIs
which have a network protocol for being dereferenced.
If you access a schema fro the URI you are dereferencingthe URI
whatever the number indirections you migh go through.

> The W3C should
>provide a proper way to define namespaces (as simple lists) and a
>way to declare schemas.

Forgive me if I am missing something but do you mean
XML Schema Part 1: Structures
http://www.w3.org/1999/05/06-xmlschema-1/

> (Furthermore, the idea of a namespace-author
>being in some way the controller of the resource for a schema is bad;

Why?

(To eleborate a little, the publisher of a reseource is the controller
of the mapping between the URI and the result of dereferencing that URI.
I should have said  "namespace-publisher".  Authors and publishers tend
to have a close understanding like a contract. But I don't think that detail
is what you are getting at)

>a schema identifier (or a namespace list) should be identified using
>the URI equivalent of a Formal Public Identifier: I can ask some service
>to provide me that schema (or that namespace list) in any format
>that anyone has chosen to make available.)


Of course. You could use an md5: for example or a uuid or a
mid: You can do that with an HTTP URI too.  You can ask anyone
for a copy of http://www.w3.org/1999/05/06-xmlschema-1/
... the HTTP 1.1 spec only gives you a cannonical way of
getting a definitive copy.

So longas you own the DNS name, you can use any part of
HTTP space as a FPI-like space.  (eg see http://purl.org/)

>>While there are many processes that can be applied to a document, and
>>correspondingly many specifications of those processes, there can be,
>for a
>>given term in a namespace, at most one correct *definition*.
>
>Again, the only declaration information that is proper to a namespace
>is a list of names. A content model is a schema, and nothing to do with
>names in a namespace, in particular.


I don't understand how you say that the content model has nothing to do
with the list of names. It lists the names and says how they can be
combined.

[...]

>Again, Andrew is simply conflating schema and namespace.  The idea that
>he and Tim are putting forward is that a language is defined by a single
>set of content models; this confuses "language" with "grammar" and
>is disproved by long-standing SGML practise,
(disproved by practise?)
> in which variants of
>a language can be defined in the same DTD (selected by marked sections,
>or by simply overriding parameter entity declarations).


You can refer to SGML as a language in its entirety,
(containing all possible bits of SGML as combined according to the
spec) and you refer to a document type in SGML as a
language, consisting of all possible documents fo a given type.
You could define the set of all parameterisable document types
as a language, or one parameterised type inwhich you
exclude any further declarations or parameterization as a language.
But if you want to keep the word "language" which has no formal
definition at all, then I will have to find another.

>I think the problem is the bad idea that content models *define* a
>language rather
>than simply *describe* or *declare* it.

I can go along with that.  A content model defines the set of names, and
constrains the
ways in which they can syntactically be combined.  Other languages
(such as rdf-schema and futher languages a la Semantic Web Toolbox
http://www.w3.org/DesignIssues/Toolbox musings) could more be said
to "define" the names in a namespace.

[...]

>>Further, I expect that one can argue that a namespace is an abstract
>concept
>>denoting a set of names, and this argument is true, so far as it goes,
>but
>>it does not go far enough:  For specific processing, to make use of a
>>namespace one needs to know what names are in it, which are not, and
>what
>>the meaning is for each name


Absolutely.  One needs to knwo the meaning of the each name
in order to know the meaning of the document.

>Here is the crux: Andrew is saying a namespace mechanism should provide
>more
>than just a space of names!  He says it should also provide meanings. If
>it does so,
>it is not a namespace, but a schema.

Hang on.  The namespace is an asbtract thing, (like software module).
A schema is a document which tells you some information about it
the namespace.

It may contain information in various langauges.  In particular,
the xml schema draft gives you a way of expressing an XML content model.
Other languages will allow one (in the same document) to provide
"meaning" by mapping onto some other vocabulary.

>Andrew is saying that we should
>not have namespaces but schemas. This is a legitimate view, but it utterly
>flies in the face of the current spec and all previous pronouncements on
>it.


I didn't hear Andrew saying that.  He seems to say "The specification does
not require that a namespace correspond to anything like a schema; but
neither does it forbid such correspondence, either
generally or in specific contexts."

>If W3C says a namespace is a schema, they should withdraw the XML
>Namespaces Spec immediately. As I emailed a month ago, Namespaces is dead.
Not by
>neglect but by abuse.

You seem agitated about this, but as I don't understand your complaint yet.
I have noone associated with W3C say that a "a namespace is a schema"
so I suppose I don't have to understand the rest of your paragraph, which ís
good because I don't.  I hope thay I can see though your clear agitation
about this to the misunderstand someone must have somewhere.

>Rick Jelliffe>

Tim BL
in no offical capacity



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)