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

Re: Another look at namespaces

• From: "Rick Jelliffe" <ricko@a...>
• To: "XML-DEV" <xml-dev@i...>
• Date: Fri, 17 Sep 1999 01:12:16 +0800

 From: Andrew Layman <andrewl@m...


>With all due respect to Simon St. Laurent, I believe that Tim
Berners-Lee
>was correctly precise when he wrote "the document corresponding to the
>namespace URI becomes
>the place where the namespace-author can put *definitive*
>information about the intent of the namespace."  (Emphasis in the
original).

The only information that properly belongs in a namespace is a list of
names.

All other information, however convenient, is not namespace information
but something else: what is this "intent" business? There is no mention
of
"intent" in the namespaces spec that I recall, quite the opposite.  The
fundamental justification for namespace is to be free from intent.

There is no W3C method to define  a namespace as list of names. There is
no
W3C method to declare which schema should be used, akin to the
stylesheet declaration. In the absense of these, of course people will
try to
turn namespaces URIs into schema declaration URLS. The W3C should
provide a proper way to define namespaces (as simple lists) and a
way to declare schemas.  (Furthermore, the idea of a namespace-author
being in some way the controller of the resource for a schema is bad;
a schema identifier (or a namespace list) should be identified using
the URI equivalent of a Formal Public Identifier: I can ask some service
to provide me that schema (or that namespace list) in any format
that anyone has chosen to make available.)

>While there are many processes that can be applied to a document, and
>correspondingly many specifications of those processes, there can be,
for a
>given term in a namespace, at most one correct *definition*.

Again, the only declaration information that is proper to a namespace
is a list of names. A content model is a schema, and nothing to do with
names in a namespace, in particular.

>[Someone] wrote that, although a schema may be somehow associated with
a
Me among others
>namespace, the "meaning" of markup will be determined in a number of
ways
>such as style sheets, or procedural code, or maybe the schema.  I
believe
>this understates the importance of the schema.  A schema makes a
>contribution to the Infoset. It does this by providing default values
and --
>under some recent proposals -- by indicating type information, which
may be
>considered also a form of default value.  Elements defined by a schema,
when
>used in an instance document in a validating processor, will have these
>default values available, and this fact is pertinent to the author of
the
>document. This means that an element is incompletely read if the schema
for
>it is not read.

This assumes that default values are not conditional or parameterized,
which in turn assumes a particular form for schemas.

But the current Infoset draft only has "the information available in a
well-formed XML document".  So there are levels of Infoset depending
on which data is considered, in progressive fashion.  In s. 7 "What is
not in the information set":
  1. The information in the XML declaration and text declarations.
  2. Element content models from ELEMENT declarations.
  3. The grouping and ordering of attribute declarations in ATTLIST
declarations.

So Andrews view seems novel. In DOM level 1 also
there is no access to content model information, which suggests that the
incompleteness of an element without a content model is minimal for
basic use of that element. Canonical XML does not include DTD or
schema.

(Furthermore, some people have  reservations that default values
are in fact part of a schema at all. )

>Unlike the various processings that may or may not be applied to a
document,
>a cited schema is part of the information conveyed by the document.
When a
>namespace has an associated schema, that schema is part of the input to
any
>further complete processing of the referencing document.  A schema is
not on
>par with other forms of processing that might be specified, say by
style
>sheets or procedural code. It is prior to other processing.

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

I think the problem is the bad idea that content models *define* a
language rather
than simply *describe* or *declare* it.  The "blink" element is not
strict
HTML; it is only an artifact of the formalism used to describe HTML
(content models on the child axis) that using a blink attribute should
require the child element to be transitional HTML.  There have been
so much criticism of DTDs and their particular limitations of
expressiveness,
yet this namespace issue utterly is dependent on a DTD-based
understanding
of what a schema should be.

An element is not defined by its content model, unless it and its
content model
are highly coupled semantically, such as tables and rows.  But frames
and
the root html element are not highly coupled semantically. DTDs and
content models (on the child axis) provide no way to model this: we
either
have ANY or a highly coupled content model. Take the example of
<p> and <blink>:  these are not semantically coupled element types--
the <blink> element type adheres to running text and the <p> element
uses running text.  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 XML Schema draft got it more right by providing
archetypes as a first-class object.

>Further, I expect that one can argue that a namespace is an abstract
concept
>denoting a set of names, and this argument is true, so far as it goes,
but
>it does not go far enough:  For specific processing, to make use of a
>namespace one needs to know what names are in it, which are not, and
what
>the meaning is for each name

Here is the crux: Andrew is saying a namespace mechanism should provide
more
than just a space of names!  He says it should also provide meanings. If
it does so,
it is not a namespace, but a schema.  Andrew is saying that we should
not
have namespaces but schemas. This is a legitimate view, but it utterly
flies in the face of the current spec and all previous pronouncements on
it.

If W3C says a namespace is a schema, they should withdraw the XML
Namespaces
Spec immediately. As I emailed a month ago, Namespaces is dead. Not by
neglect but by abuse.


Rick Jelliffe


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: Paul Prescod <paul@p...>

• 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