xml-dev - Re: [Fwd: ATTN: Please comment on XHTML (before it's too late)]

["W. Eliot Kimber" <eliot@isogen.com>]

David Megginson wrote:
> 
> W. Eliot Kimber writes:
> 
>  > As I said in my post, the reverse is possible: a semantic definition
>  > (e.g., XLink, RDF, XHTML) can state a binding as part of its
>  > specification (which is exactly what the XLink spec does), but you have
>  > know about that statement before you start processing a document. To do
>  > that, you have to read the spec. Once you read the spec, the use or
>  > non-use of name spaces is irrelevant for the purpose of recognizing
>  > element types defined in a given spec--there are any number of ways
>  > names can be disambiguated or bound to name spaces. The namespace
>  > mechanism is only one, and it's a particularly weak one at that.
> 
> The first part of the statement is a truism -- with few (if any)
> exceptions, there are always different ways any standard could be
> implemented.  IP could have been designed dozens of different ways,
> but that does not make IP irrelevant.

My point is that namespaces, by themselves, don't help (or hurt) in the
recognition of names that you know--thus they are irrelevant to the
problem of name recognition.  Once you've read a particular spec, you
know how that spec defines names that you can recognize. Given the name
of a name space, it is impossible to know in the general case what
semantic definitions, if any, might relate themselves to that name
space. So you always have to have come across the semantic spec first
(or be lucky in your search of available documents). If the spec you
have (or find) uses namespaces, fine, now you know, but if it doesn't,
you know that too.  Thus, there's nothing magical about namespaces with
respect the problem of name recognition. And there are a lot of things
that are suboptimal about name spaces (such as no way to map a single
element to names in multiple spaces).
 
> In fact, SGML itself (and XML 1.0) define only names scoped to a
> specific document type, so there are two types of a-priori knowledge
> necessary to recognize names:
> 
> 1. You have to know (somehow) what the document type is (as Eliot has
>    often pointed out, the DOCTYPE declaration doesn't help); and
> 
> 2. You have to know (somehow) what the element or attribute name
>    means.
> 
> There have been two significant attempts to remove the first of these
> problems, so that arbitrary names can be recognized in any document:
> Architectural Forms and Namespaces.  To establish names that can be
> recognized outside of document types, it is necessary to make them
> globally unique: Architectural Forms does so by associating each name
> with a formal public identifier, while Namespaces does so by
> associating each name with a URI.
> 
> Neither Architectural Forms nor Namespaces can offer a solution to #2
> -- after all, the range of possible meanings is potentially infinite.

Not quite true--the key difference between architectures and name spaces
is that the architecture mechanism provides three things that the
namespace mechanism does not, including as much of the solution #2 as
you can get in this context:

1. A formal and standardized mechanism for defining the vocabulary of
names used in an architecture (architectural DTDs defined using DTD
declarations as standardized in ISO 8879 and XML 1.0 Rec)

2. A formal and standardized mechanism for binding a document to the
*semantic definition* of the architecture. That is, the external
identifier for the architecture *by definition* points to the
documentation of the semantics for that architecture. That's the best
that *anyone* can do. Once you get to the documentation, it's up to you
to interpret it. The documentation can include both machine-readable
formalisms (e.g., schemas of some sort) and human-understandable prose. 
But note what this means: having come across an architecture use
declaration, I can get to the definition of the architecture if I can
resolve the external identifier. 

Point of fact: The external identifier for an architecture need not be a
public identifier. It can be any form of external identifier, including
a URL. In fact, it probably should *always be* a URL so you have some
hope of finding the damn thing.

3. A formal and standardized mechanism for defining type hierarchies of
element types (architectures derived from architectures).

Thus, while name spaces and architectures are both fundamentally about
names, the namespace mechanism provides only for the uniquification of
names, while the architecture mechanism provides for that as well as the
other things you need.

Note that there is no necessary conflict between name spaces and
architectures--they use different syntactic mechanisms and could be used
together, either synergisticaly or not. There is also no conflict
between architectures and XML Schemas--I would expect XML schemas to be
a core part of the definition of the semantics of architectures and I
would expect XML schemas to provide better mechanisms for what
architecture *syntax* does today.

But it is not fair to say that name spaces and architectures solve
*exactly* the same problem. The problem that name spaces solve is a
proper subset of the problems that architectures solve.

Cheers,

E.

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