Another look at namespaces

[Tim Berners-Lee]

-----Original Message-----
From: David Megginson <david at megginson.com>

>Tim Berners-Lee writes:
>
> > What happens when a version one program meets a version 2 document?
>
>As Tim points out, this is (or at least, should be)
>application-specific.  I have omitted his summary, but I agree with
>its broad outlines.


I'm not sure what you mean by "application -specific".  If you mean
that one is entitled to do feed a document into any app program and
depending on what the program does anything can happen, and
be taken as a valid interpretation of the document, then no!
My point was that the combination of the document and the definition
of the language it is written in have a certain meaning and that nothing
must be allowed to produce a different (contradictory or superset)
meaning ostensibly from the original document.

>Unfortunately, I think that Tim B-L and Paul Prescod are wasting a
>little of their typing preaching to the converted;

Good.  Then my message can be consided a summary I guess.

> we all (or at
>least, most of us) agree and always have agreed that the following are
>basic requirements for dealing with Namespaces:
>
>1. An application must be able to determine the general language used
>   by (part of) a document.

>2. An application must be able to determine the specific dialect used
>   by (part of) a document.
>3. An application must be able to locate schemas, stylesheets, and
>   other materials related to a language (or dialect).


Here you introduce a distinction between a "general language" and
a "dialect".   I am not convinced that this is a well-defined concept.
I feel that language subsets are completely well defined, by the change
of namsespace preserving validity.
What is the definition of a "dialect"?

To me, nesting a level of naming of "version" inside a "general" language
suggets that nothing at all is really known about the general langauge.

>What is contentious is not whether these three requirements are real,


I'm not currently accepting the concepts on which they are based.

[...]

If as I fear, the "general language"  refers to some approximate
similarity then I would not want one single ecommerce application
or data-in-xml application to use the concept. A langauge
is a language IMHO.

I think that you can in fact crystalize the concept of "general language"
by specifying a set of languages which are all subsets of a given
language L.   So for example if you define xHTML-all as a
language whose document content model accepts any strict or
transitional or frameset document, then you can use that 
namespace for refering any xHTML document.  You now have a clean 
definition of validity, and well-defined compatability rules.

>b. the applications concerned only with #1 will tend to be the
>   lightest-weight ones.


I do not believe that lightweight applications will just be fuzzy.
You can imagine them for simplicity just advertizing a
few superset languages as things they accept.


I would not be in favor of anything which made the precise definition
of the language in which a document was written anything other than
a URI.  You can introduce more metadata about a namespace 
and enrich the world, but let's keep a namepsace a namepsace
as identified by the namespace URI.

>We mustn't make easy tasks difficult for the sake of theoretical
>purity -- I know, because we tried to do that over and over again in
>the SGML world, and, well, we're not debating SGML any more, are we?

I hope not.
But in general simplicity tends to make easy tasks easier.
If it didn't happen in the SGML design I who was not there cannot comment.

You can in general optimze things which are well defined cleanly.


Tim BL



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)