W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 1999

Re: Namespaces are dead.

From: Steven R. Newcomb <srn@techno.com>
Date: Sat, 5 Jun 1999 15:30:35 -0500
Message-Id: <199906052030.PAA28464@bruno.techno.com>
To: tbray@textuality.com
CC: ricko@allette.com.au, xml-dev@ic.ac.uk, www-xml-schema-comments@w3.org
> Architectural forms were rejected because it was a design goal to
> assign namespaces both to elements and to attributes, and the AF
> syntax for doing with this attributes was felt to be indefensibly
> hideous. 

Hideousness is in the eye of the beholder, but I think we're at
cross-purposes.  The issues here go far deeper than syntax.  Syntax is
just *how* we say something.  *What* we say is infinitely more
important, just as the whole architectural forms paradigm is
infinitely more significant than the question of how we declare its
use.

> As David Megginson has pointed out on several occasions, namespaces
> solve an entirely different problem, and interoperate with AFs just
> fine.

What, exactly, is the nature of the real-world problem that namespaces
are the key to solving?  Namespaces are still *perceived* as solving,
and are often *sold* as solving, a problem that they do not in fact
solve: the problem of allowing information to be exchanged in a truly
open marketplace.  Namespaces are being sold as the key to
interchanging e-commerce information.  And they will work for that
purpose, BUT NOT IN A VENDOR-NEUTRAL CONTEXT, in which every system
vendor can participate on a level playing field with every other
system vendor, with a reasonable expectation that information will be
reliably interchanged, regardless of who made the software that
produces or applies the information.  

If I had ever thought that XML, nee SGML, could not be used by the
public to create such a level playing field, I would have lost
interest in it then and there.  That's why I react so negatively to
"namespaces".  They seem to me designed to make private languages, not
public ones.  Namespaces provide absolutely no way for the
information-using public to create (and demand software conformance
to) whatever information architectures it deems appropriate.
Namespaces put all control over every aspect of information
interchange in the hands of whichever software companies already "own"
a given user base.  I put it to you very baldly: namespaces work
against the public interest, and in favor of existing software
monopolies.  It doesn't surprise me that Rick Jelliffe has detected a
conflict between BizTalk and other attempts to rationalize e-commerce,
nor am I surprised that the conflict exposes an impedance mismatch
involving namespaces.  I keep hoping that people will wake up to the
real requirements, and the real public interest issues here.  That's
why I'm bringing up architectural forms, for the umpteenth time, in
this forum.  I'm hoping that people will recognize that the
interchange of commercial information requires *common* *public*
languages, while "namespaces" are, at best, *private* languages that
are inextricably entangled in particular software applications.

Architectural forms provide a syntax (about which I care nothing --
let's agree on new syntax that you like, Tim), and a paradigm (about
which I care very passionately) in which we can have *validatable*
*common* *public* vocabularies that can be used for interchangeable
information.  In the AF paradigm, in any given application, we can
have a re-usable plug-in engine for each vocabulary.  The means
whereby that magic is accomplished is the grove paradigm.  It may or
may not be relevant that all this is already standardized in ISO/IEC
10744:1997.  The fact is, it works, and it is urgently needed for
medical records, e-commerce, and other major applications of XML.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@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
Received on Saturday, 5 June 1999 16:34:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:12:46 GMT