why do namespaces have such a bad rep [2]

[Steven R. Newcomb]

[James Anderson <james.anderson at mecom.mixx.de>:]

> first, an aside for those who may wonder why i pursue this. my
> concern is that i do not wish to have to implement support for
> enabling architectures just in order to contend with name
> collisions. on principle it would be wrong.  practically it would be
> a waste of time.

(1) You don't have to implement it.  It's already implemented.  It's
    already free, in source form, too, without restrictions of any
    kind, except that you can't use James Clark's name in certain ways.

(2) If you're determined to argue this point on the narrowest possible
    grounds (even though those are not the grounds I'm arguing on),
    how's this?  "Enabling architectures, among many other things,
    is a way of handling name collisions.  If the sole purpose of
    namespaces is to avoid name collisions, and if you don't have
    to implement enabling architectures, then on principle it's a
    waste of time to implement namespaces.  Q.E.D."

(3) Enabling architectures would enable RDF to meet real requirements
    and desiderata that RDF can't satisfy today because it doesn't
    have enabling architectures.  The simplifying assumption that
    namespaces represent ignores and renders useless the most powerful
    aspects of the schemas that represent architectures (i.e., DTDs).
    Among other things, RDF is supposed to support electronic
    commerce.  Electronic commerce is a limitlessly hard problem in
    data interchange and management.  It's not a good idea to discard
    or cripple the tools we already have for dealing with hard
    problems in data interchange and management.

The namespace solution and the enabling architectures solution are
*not* orthogonal to each other, unless you restrict your vision to
extremely narrow and purely implementational concerns.  If you're
sensitive to the economics of mindshare, or to the very real cost of
having two things, one less powerful than the other, where the one
more powerful thing alone will do the job, you will see the
connection.

Let me put it even more starkly.  It makes no sense, in a small living
room (the short supply of mindshare and attention), to replace a
comfortable sofa (enabling architectures) with a rude wooden bench
(namespaces).  It doesn't matter how many times you say that the
wooden bench is perfectly good for the purpose for which it was
designed, and it doesn't matter how many times you point to the
bench's original specifications when people complain that, in
practice, the bench is sometimes very uncomfortable and a sofa would
be much more useful in a wider range of everyday living situations.

> i use namespaces. i have implemented namespaces.

I suspect yours is a very fine implementation, too, and, believe me, I
sympathize with your situation.  My company has done several
implementations of nascent standards, only to throw them away and
start over when it became clear that any tendency on our part to cling
to our investment would stand in the way of progress in the larger
context.  Our HyQ implementation is an example.  Perhaps you remember
HyQ, the HyTime query/addressing language that was replaced by SDQL --
a replacement that I firmly and immediately supported, despite the
emotional stress of abandoning a pile of work and a substantial
investment.  (Don't get me wrong; I've never regretted it.)

> you're right there. one thing i still need to understand is how i would, for
> example, define things like the ArcCFC entities for multiple inherited
> architectures (ISO/IEC 10744 p230), or handle possible name ambiguity between
> multiple architecures wrt entities used to specify section inclusion (ISO/IEC
> 10744 p223)
> (yes, i lack experience there. i woud presume one helps oneself to dotted names,
> but that's just conjecture)

The parameter entity namespace collision problem can occur only when
you're syntactically inserting a DTD into the architecture you're
creating.  The potential for parameter entity name collisions, in such
a scenario, is a feature of (or, one could conceivably believe, a bug
in) SGML's DTD syntax.  Fortunately, such inclusion is never necessary
in order to obtain the full benefit of enabling architectures; you can
always just map everything you need in the usual fashion, by declaring
element types in your inheriting DTD that conform to architectural
forms (the element types in the inherited-from DTD), and thus refer
to, rather than include wholesale, the enabling architecture's DTD.
If your enabling architecture has ArcCFC parameter entities, simply
expand them in the normal SGML way, see what effect they have on the
enabling architecture's effective DTD, and use the result as your
enabling architecture.  You always have the option of allowing
whatever was declared as context-free in the enabling architecture to
be used with equal lack of constraint in your inheriting architecture.
Or, you can constrain the context-free elements to appear only in
certain contexts; it's up to you.  Whether you choose to declare
context-free elements by means of a parameter entity whose name
happens to be %ArcCFC; is entirely your business.  (All parameter
entity names in your inheriting architecture are entirely your
business.  In fact, even when inheriting any number of enabling
architectures, means are provided to allow you to prevent them from
affecting any of the inheriting architecture's namespaces in any way.)

The marked section modularization technique used in the 1997 HyTime
architecture has nothing to do with the concept of enabling
architectures.  The marked section stuff in the HyTime architecture is
just a technique that helped us get the HyTime standard published in a
way that allowed the whole HyTime architecture to be
self-documentingly and self-realizingly modular.  It is a pretty cute,
if somewhat Byzantine technique, but it seems obvious, in retrospect,
that the modularity of the HyTime architecture would have been better
and more neatly achieved by making each of its modules a distinct
enabling architecture.  Unfortunately, that realization didn't dawn on
us in time to meet the 1997 edition's publication deadline.  *Sigh*
Live and learn.  Sorry for any confusion it causes.  (The concept of
enabling architectures has nothing to do with the HyTime architecture,
either, except that, (1) when used as such, the HyTime architecture is
just an example of an enabling architecture, and (2) both the HyTime
architecture and the enabling architectures paradigm are standardized
in single ISO book under a single ISO standard number, viz.,
10744:1997.)

Anyway, please understand that I'm not trying to defend particular
syntaxes.  By speaking out against XML namespaces, I'm attempting to
conserve the public's mindspace for underlying concepts and
intellectual tools.  With the minimum set of the most protean possible
concepts and intellectual tools, we may hope to grope our way toward
more intuitive and more convenient schema syntaxes.  On the other
hand, with a wildly overlapping set of specialized, narrow-gauge tools
(XML namespaces leap to mind as an example), I doubt we can ever get
to a place where we have a really good, fully generalized schema
syntax.  In that case, I think we'd better stick to SGML's DTD syntax,
warts and all, because it is known to work and, as an existing
international and W3C standard, we won't have to fight over it.  We
can just keep on kludging it up with things like colon-ized namespaces
and architectural form attributes.

To all those who have read this whole harangue: you have my thanks and
sympathy.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn at techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137)
fax    +1 972 994 0087 (at ISOGEN: +1 214 953 3152)

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)