[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Another look at namespaces

• From: David Brownell <david-b@p...>
• To: Tim Berners-Lee <timbl@w...>
• Date: Thu, 16 Sep 1999 02:12:33 -0700

Tim, thanks for sharing your perspective ... there's been a certain
feeling that it has been both missing and necessary!  :-)


Tim Berners-Lee (timbl@w...) wrote:
> 
> I have no passionate personal concern as to whether XHTML spec defines 3
> languages or one, but the HTML 4.0 spec defined three,

In HTML 4.01, section 2.2 "What is HTML?" talks about "a language" and
"the language", never "three languages".  There are three DTDs, yes;
but they're never explained as different languages.  One language,
three DTDs (feature deprecation issues) -- from the HTML 4.0[1] spec,
I searched a dozen sections and found no "three languages" comments.
Was something hidden away?

In short, what you wrote is confusing to me since its use of "language"
seems like it isn't the one currently used by W3C.  When you wrote
"language" here it seems like the correct terminology is "DTD"; that
has significant implications.

New terminology here would be especially troublesome as it eradicates
a fundamental notion.  Namely, that a language is a vocabulary, as
distinct from the grammar rules constraining differents sorts of
usage.  If that's intentional, I think it's an issue deserving some
discussion in its own right.  Not to get sidetracked on "what is
language"; but just to maintain that basic separation between the
notions of vocabulary and grammar.


And in your second post:

> I feel that language subsets are completely well defined, by the change
> of namsespace preserving validity.

That's not quite clear to me.  Why would I change the namespace URI
when the information (and even structure) is unchanged?  Why wouldn't
I just swap some validity rules and leave the namespace(s) alone?

After all, the elements and attributes haven't changed meaning,
only something about the manner in which they're validated.  Keep the
simple stuff simple:  vocabulary != grammar.


> It is important to realize that these are *different* languages.
> If you take a Transition document and re-label it as a strict document
> it can be invalid. Invalid by specification, whether represented by English
> or DTD or schema.

If some particular document doesn't validate against the strict DTD,
that seems to me like it's _just_ a validity issue.  Doesn't affect
the language at all; "say it ain't so!" is English, albeit not what
a grammar teacher would applaud.


That is:  the "rules" (validity as checked by DTD, schema, app)
are distinct from the "language" (vocabulary).  Rules that only
permit a subset ("strict" etc) don't create a new language.

Rules that combine different vocabularies are clearly going to be
an interesting game to play ... and unfortunately I don't see how
an XHTML spec constrained by HTML 4.0 compatibility can afford to
have separate namespaces for the non-strict chunks of vocabulary:

    <p>An <em>emphatic</em> objection.</p>

    <p>A <deprecated:font size="+4">big</deprecated:font> toy.</p>

Any HTML browser would be upset at seeing the latter, and of course
it's not possible to validate it without freezing the prefixes (bad).
But with one XHTML namespace, everything's fine -- use validity
checking for its job (help phase out those deprecated tags, <blink>,
and so on), and most existing HTML agents will work fine.


> the document corresponding to the namespace URI becomes
> the place where the namespace-author can put *definitive*
> information about the intent of the namespace.
> And this is not mandatory - but is very useful!

Not "the place" as in one-and-only-possible.  One can easily
define elements to hold such associations without needing to
overload usage of the namespace identifier (URI).

By the way -- which types of information?  And what about
information describing the way namespaces may combine,
rather than information about some individual namespace?
Or information that's part of _my_ intent, additional to
that of the various namespace authors I'm leveraging?  It's
likely I may want to constrain some legal usage.

If one uses separate elements to hold the associations, one
gets flexibility to represent many such types of information.


> The exciting use of namespaces in schemas will be when ...

That's all quite true!  But it doesn't require any inflexible
one-to-one association of namespace URIs and schemas (or DTDs).

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: Another look at namespaces
    • From: Ann Navarro <ann@w...>

• References:
  • Re: Another look at namespaces
    • From: "Tim Berners-Lee" <timbl@w...>

• Prev by Date: RE: Another look at namespaces
• Next by Date: Re: Another look at namespaces
• Previous by thread: Re: Another look at namespaces
• Next by thread: Re: Another look at namespaces
• Index(es):
  • Date
  • Thread