Namespaces are dead.

[Steven R. Newcomb]

[Rick Jelliffe:]

> In other words, namespaces are dead (for database documents) as ways
> of uniquely naming elements independent of any other
> considerations. They are now
> "name-in-a-particular-schema-in-a-particular-schema-language--spaces".

> The practical question is now what to do? Should we just lay down and
> die; should we go back to architectural forms; should we invent a
> parallel namespace PI that is concerned with uniquely identifying
> names and not with tieing elements to a schema?

I'm glad you brought this up, Rick, because I have never heard a good
argument as to why architectural forms were rejected in the first
place.  To me, it looks as though they were rejected simply because
many RDBMS applications professionals don't yet think in
object-oriented terms.  (But that's changing.)

Architectural forms handle multiple inheritance very gracefully, and
they are based on a paradigm (the Grove Paradigm) within which
re-usable software modules for inheritable architectures can cooperate
in arbitrary combinations within applications that understand multiple
vocabularies, even when vocabularies are combined arbitrarily in XML
resources.

Architectural forms work with or without a DTD; with architectural
forms, the DTD becomes merely a markup-minimization device.
"Meta-DTDs" (or "meta-Schemas", if you prefer) are the basis of
primary syntactic validation.  "Architectural definition documents"
are the basis of subsequent semantic validation.  Architectural
"property sets" expose the information sets of resources that inherit
architectures.

Architectural forms provide a means of validating resources against
the real syntactic and semantic requirements involved in using what
are commonly called "vocabularies", thus meeting a real, basic
requirement that W3C "namespaces" have never met, and that
*vendor-neutral e-commerce must have*.  For a general introduction,
see my slides from XTech '99, http://www.hytime.org/papers/srnXTech99

I hate the idea of further fracturing the solution space with yet
another PI which will be in partial conflict with other XML features.
Now is the time to have a sensible, hard-working solution for
inheriting multiple vocabularies.  XML Schema isn't quite there (yet),
but it could easily get where it needs to be, and I have high hopes
for it.

Anyway, until I see something better, my money's on the Grove
Paradigm.  I don't see anything else (yet) that will really meet all
the requirements and really provide a stable path forward for the
indefinite future.  If we already know a correct answer, and our need
for a correct answer is urgent, why don't we accept it and improve on
it?  In any case, the Grove Paradigm is already inevitable in ERP and
other high-end corporate memory applications, including Topic Maps.

-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/ and on CD-ROM/ISBN 981-02-3594-1
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)