Another look at namespaces

[David Megginson]

Paul Prescod writes:
 > Rick Jelliffe wrote:
 > > 
 > > 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" 
 > 
 > What definition of language are you using that does NOT state that every
 > language has one and only one grammar. Is there a book I can read that
 > defines it? The SGML Cookbook doesn't count.

Well, for natural languages, there is almost never a single grammar:
it varies (sometimes dramatically) by time, place, gender, and social
background.  

The different grammars share certain patterns, which you can collect
into a meta-grammar if you wish, but that meta-grammar is necessarily
descriptive, fuzzy, and incomplete (the next field researcher in New
York City, Nairobi, or Kingston, Jamaica could find an example that
forces us to change the meta-grammar). 

 > > and
 > > is disproved by long-standing SGML 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).
 > 
 > SGML does not (AFAIR) define the word "language." It defines the word
 > "document type" and a document type has one and only one grammar. 

That's the spec, not the usage.  In SGML practice, a single document
type (lower-case) is almost always defined by multiple DTDs: in other
words, the spec got it wrong, so the implementors simply worked around
it.

 > But as Tim B-L and I both said, the important consideration is temporal.
 > XHTML 1.0 could be defined with one of these "parameterizable grammars".
 > We could have one dialect and neither of us would care much. But it
 > would set a bad precedent because it would validate this fuzzy notion of
 > "wink, wink, we know what a language is, nudge, nudge." This will cause
 > problems over time when new versions come about.
 > 
 > Assertion: Once there are deployed XHTML processors it should be
 > absolutely illegal to silently pass off new, incompatible versions as if
 > they were the same as old versions. New, compatible versions (e.g.
 > subsets) are not a problem.
 > 
 > A version attribute has a few problems
 > 
 >  * it is HTML *specific* -- every document type has versioning issues
 > and every document type (now) has a different approach to it. There can
 > be no general version-handling "engine" as long as this is the case.

It can become conventional for languages that need it, like the Perl
$VERSION attribute.  Standards writers hate conventions (because they
didn't get to invent them), but those of us in the U.K, Canada, and
the U.S., at least, are very used to the idea that The Law is a
combination of statutes and common law.

 >  * the version attribute doesn't tell a new processor what it needs to
 > know in order to know whether it can process the document safely. Once
 > again, there is no standard for communicating *what has changed*.

Neither does the Namespace URI -- that information is available only
through outside documents (schemas, or what have you), and there is no
absolutely no difference in the mechanism for retrieving them using
the Namespace URI or the value of the version attribute.

 [snip]

 > The modelling language isn't the issue. The resulting grammar is the
 > issue. You could use prose to define XHTML -- if there are three
 > grammars there are three languages. If you use a flexible grammar
 > notation that allows the three grammars to be collapsed into one (such
 > as prose) then you have one language.

This is a puzzling statement -- in other words, if I use notation A to
describe it, XHTML is three languages, but as soon as I switch to
notation B, it magically becomes one?  I suppose that Derrida would
approve.


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)