Re: Thoughts on namespaces

At 06:49 PM 5/22/97 GMT, Christopher R. Maden wrote:
>[Eliot Kimber]
>> Why not use architectures for this?  Instead of qualifying the GI,
>> you create a local element type name and then name the form from
>> which it is derived (here deriving "mylink" from the HTML element
>> form "A"):
>> 
>> <mylink html="a" href="foo"/>
>
>[...]
>
>> While I can see the appeal of being able to do some sort of "import"
>> of one DTD into another, I think the basic requirements can be
>> solved adequately (if not ideally) using existing mechanisms without
>> the need to modify XML or SGML syntax.
>
>I think that what the requestors are requesting is the ability to say,
>"Gimme stuff from HTML and gimme stuff from MathML and know what to do
>with them, without me having to make a DTD that explicitly merges them
>all."  Using arch forms, while elegant, requires either a DTD for
>#FIXED attributes or explicit attributes on every element instance.
>(Or a #CURRENTy thing, but let's not go there again.)

Right, but merging the name spaces requires putting the name space name in
the GI.  The only difference between that and using an attribute is
brevity, and only when there is no explicit DTD (in which case the
attributes can be fixed, resulting in maximum instance brevity).

If I understand the request as stated, it's a way to combine *semantics*,
for which element type names are merely arbitrary labels.  People seem to
be thinking that the name *conveys* the semantics.  It doesn't.  It is
merely a pointer to the semantics.  Attributes can point to those semantics
just as well as the GI can, and with more flexibility.  In both cases you
must have a reference to definition of the semantics (which is done for
architectures by declaring the architecture as a notation, which points
both to the architecture definition document and the architectural meta-DTD).

In the discussions I've seen (both here and elsewhere), there seem to be
several distinct and largely independent problems:

1. Connecting instance element types to known semantics ("architectures")
2. Managing "DTD modules" in some semi-automatic way ("schema import")
3. Enabling the literal inclusion of document fragments with different
   schemas in the same document ("inline subdocs")

Of the three, only 2 is not satisfied to a significant degree by existing
(and implemented) mechanisms.

Problem 1 is solved by architectures, as discussed, and implemented by a
number of tools, most completely by SP.

Problem 3 is solved by not doing it: use indirection instead (as explained
in my XML DEV post and in more detail in my SGML '96 paper *SUBDOC: Why I
Demand It*, www.isogen.com/papers/subdoc.html).

Problem 2 is only a problem *when you have explicit DTDs*.  If you don't,
then there's no problem because there are no constraints on content.  The
Japanese delegation to WG8 presented a very clever proposal that is similar
in intent and mechanism to various proposals I've seen here that borrow
from Modula 2 and the like.  In the time we had to analyze it at the WG8
meeting, we couldn't find any obvious problems with the proposal (we
tried). I've no doubt that these proposals could work, but I question their
cost to benefit ratio--it seems like a very big hammer to solve a
relatively small problem.  Certainly the complexity implied by an import
mechanism is much migher than, say, notation attributes or other useful
SGML features XML left out.

Cheers,

E.

Received on Thursday, 22 May 1997 16:18:26 UTC