Another look at namespaces

[Paul Prescod]

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.

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

Even if we ignored this we could say that SGML use a very flexible
grammar definition language that defines grammars that are not
context-free or hedge-regular or whatever. Grammars can be
paramaterizable, extensible and otherwise complex.

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.

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

"Rip Van Winkle, the language has changed. Certain of your grammatical
constructs have become offensive. You will be shot if you use them"

"Can you tell me which ones?"

"Sorry, you'll just have to learn by experimentation."

> If the <blink> element is removed, it is the
> declarations
> for running text that should be changed, not the declarations for <p>.
> DTDs only provide parameter entities for this, which disguises this
> basic
> modeling truth. 

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. But if we define HTML's grammar
*today* so that it automatically allows any extension we can think of in
the future:

<!ELEMENT p ANY>
<!ELEMENT body ANY>
<!ELEMENT h1 ANY>

Then we have issued an invitation for massive abuse by software vendors.

> If W3C says a namespace is a schema, they should withdraw the XML
> Namespaces
> Spec immediately. 

There is a world of difference between saying that a namespace *is a
schema* and saying that there are a set of W3C specifications (including
XHTML) that have namespaces that have a one to one correspondance with
schemas. It's like saying that "p" doesn't have to be defined in a DTD
(because not every XML document has DTDs) but the *HTML* "p" *is*
defined in a DTD (which has been the stance since HTML 2).

 Paul Prescod



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)