Another look at namespaces

[David Megginson]

Tim Berners-Lee writes:

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

No, that's not quite what I mean -- I mean a combination of
"application" in the SGML sense (i.e. the XHTML Namespace or document
type) and "application" in the marketing sense (i.e. a Web browser).

It's difficult for a designer to anticipate all of the expected uses
of a Namespace -- for example, it's quite reasonable to specify what
*browsers* should do when the find an unknown element type in an HTML
document, but should the same behaviour apply to (for example) to
search engines and text repositories?  I'd be very upset if an XML
repository automatically stripped out unrecognized element boundaries
when I checked in an XHTML document.

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

Yes, but unless the Namespace is irrevocably tied to a very specific
processing model, its definition (human-readable or otherwise) will
necessarily provide only partial information.  The Namespace
definition says *what*, but it cannot usually say *how*.

 [snip]

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

The boundary between dialect and language is not crisp.  I am
absolutely certain that C++ and HTML are different languages, and I am 
fairly certain that HTML 4.0 transitional and HTML 4.0 strict are
different dialects of the same language, but I don't know where to
draw the line in the middle: are C and C++ (for example) different
dialects or different languages?

As with natural language, the best test is interoperability, even if
the results are not always conclusive (as in my C/C++ example).  My
Web browser works more-or-less properly with HTML 2.0, HTML 3.2, HTML
4.0, and XHTML, without knowing in advance which of those it's going
to see (all it gets is the MIME type text/html) -- for me, that's
proof that they are all dialects of the same language.  Certainly, a
multi-billion dollar industry is based on that assumption.

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

That's obviously a deliberate overstatement -- Netscape and MSIE work
most of the time, even though they work at what I'm calling the
language level; we're simply dealing with a 20,000-foot view rather
than a 2,000-foot view.

It's not a perfect analogy, but take a look at a MIME type like
text/html or image/jpeg -- it is often possible to perform useful
sorts of processing on all image/* or text/* resources.  Two-level
hierarchies are well-proven and well-deployed, and in the case of a
language (Namespace URI) and dialect (version) pair, the two levels
will provide much more precise information than a MIME type.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

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)