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

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

David Megginson wrote:

>  > But that requires a lot of machinery, which is probably beyond the
>  > W3C to define at this point in time.
> 
> The definition is not the problem -- the implementation and deployment
> is.  Any standard that requires the processing of a large schema to
> make sense of a small XML document will probably fail.

I'm talking about definitional machinery, not processing machinery. All
I really want is an explicit names-space-to-schema binding. That is,
something stated *in the document* that I can rely on as the basis for
mapping element instances to semantics. I don't have to *process* the
schema in order to do that (any more than I have to validate a document
in order to process it). But I do have to have a reliable *name* for
semantic definition, and the name-space name *IS NOT IT*. And pretending
that it is is dangerous at best.
 
> XML Namespaces cannot work the same way as classes and interfaces in a
> closed system -- all of the useful information (or at least enough of
> it for processing) *has* to be in the document instance itself, not in
> a separate schema that might reference another schema that might
> reference another schema, etc.  That means that a Namespace URI is a
> lot like a domain name -- a single, well-known public identity for a
> collection of markup definitions -- and not very much like a class.

No--it should be that, but it's not, because nothing the namespace spec
provides for the binding, therefore, there is no way to put the binding
in the document. How hard is this to understand? 
 
>  > It also points up a problem with simple-minded processors that make
>  > assumptions about local names that are not justified.
> 
> Simple wins, complex loses.  I remember avidly reading the literature
> about the complex experimental hypertext systems of the late '80s and
> early '90s, but they lost and HTML won.  Now, maybe HTML was a little
> too far on the stupid side, but not so far that it couldn't mop the
> floor with the competition.

Yeah, but we're beyond the level of simple win that HTML was able to
give us. The best we can do is build some conventions that make the
*default* use of a more complex mechanism simple. That's what we tried
very hard to do with HyTime and anchitectures. But you have to have all
the formal definitional mechanisms behind it or its just a set of
conventions, not a reliable, extensible, formal system. You can't have
it both ways.

For example, the namespace mechanism could have been defined such that
*by default* the semantic name was derivable in some way from the
namespace name or visa versa. But without a formal definition of even
how to refer to semantic definitions, there's no framework within which
to even define this default behavior (default relative to what?). 

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)