xml-dev - Re: Namespaces: silly question

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

At 02:43 PM 8/7/98 -0400, John Cowan wrote:

>I'm not sure what you mean. There is no way to declare a root element
>in a DTD. Paraphrasing Eliot Kimber, a DTD is nothing more than a 
>collection of markup declarations. Nothing in a DTD actually describes
>a document, merely structures that might make up a document. The root
>element can be almost any element (RefEntry rather than Book in DocBook,
>forinstance).

Any element can be a document element. Consider:

<!DOCTYPE Foo [
 <!ELEMENT foo 
   EMPTY
 >
]>
<Foo/>

This thread I think points up what I've been saying since the beginning of
the name space discussion: the name space proposal doesn't solve any
problems that weren't either already solvable by existing means (e.g., SGML
architectures) or that can't be solved in a general way (blind syntactic
combination of declaration sets or document  fragments).

All namespaces do is provide the illusion that you have some control over
the problem space. But the fact that you must rewrite both declarations and
instances in order to have something validatible suggests that there is no
more control than there was before.  

There are two basic cases at work:

1. A single document that uses element types from different sources
2. The combination of otherwise independent fragments into a single
syntactic instance (e.g., use-by-reference of one document by another).

In the first case, if you use architectures to declare the mappings from
element instances to governing vocabularies, then no rewriting is necessary
in order to validate either the instance against its private DTD or against
any one of the governing vocabularies because there is no *syntactic*
interaction between the different name spaces except at the level of the
name of the attributes used to map elements to architectural names,
something that is trivially easy to disambiguate at the time a declaration
set is defined.

In the second case, if you use independent documents to manage the data and
then want to combine them, the rewriting you have to do when using
architectures is essentially the same that you must do if using name spaces:

- Generate unique element type or attribute names and transform input
instances to these new names (disambiguates name clashes). The new names
can either be arbitrarily generated (they have no semantic significance in
any case) or taken from one of the governing architectures (there could be
more than one architecture governing a single element).
- Generate new architectural mapping attribute names (equivalent to
namespace prefixes in function) where two documents use the same attribute
name for different architectures (unlikely but possible) and use these new
names to describe the mapping.
- Generate new declarations reflecting the new names (pointless but
possible--since you are combining things blindly, there's no benefit in
building local declarations that allow the resulting instance to validate,
especially as the document can still be validated against the architectural
DTDs as in case (1). The only value to local declarations would be for
attribute default specification, but that doesn't require any content model
munging and so is very simple to do).

The result will be single document with no name clashes and the mapping of
element instances to architectural element types preserved.  The result can
still be validated against any of the governing architectures.  

Note that if you want to craft the union of two previously uncombined
architectures (DTDs) then you do so by creating a new architecture that
reflects the crafted result. While the combination can be started by a
machine, it requires human intelligence in the general case to finish the
combination because either arbitrary or aesthetic choices need to be made.
The definition of document structures is a creative act and therefore
cannot be completely computerized.

Architectures also have the advantage that, unlike name spaces, they
provide *both* a definition of vocabulary and a definition of semantics
(although how the semantics might be defined is up to the creator of the
architecture).  Because architectures use normal DTD syntax for defining
their vocabulary and minimal validation rules, they are grounding in an
existing and stable standardized syntax (SGML/XML DTDs) and do not require
the invention of any additional syntax or processing machinery to enable
validation of documents against vocabulary and structure/syntax rules.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

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/
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)