xml-dev - Re: XML complexity, namespaces (was WG)

["Steven R. Newcomb" <srn@techno.com>]

[Richard Goerwitz:]

> [Certain members of] ...the old SGML community... looks to
> me as if it's trying to kludge architectural forms onto
> XML, maybe in efforts to save DTDs.

I would plead "Guilty as charged" if you said basically the
same thing in a more positive way, and without the implicit
accusation of syntax-bigotry:

  "Certain members of the SGML community are demonstrating
   how to use architectural forms with XML.  Thus they are
   promoting the concept of structural and semantic modeling
   and validation in XML."

It is largely immaterial whether the old DTD syntax survives
in XML-land.  However, the idea of validatable structure is
of vital importance if we're to have efficient, reliable
information interchange via XML resources.  If an XML
resource uses more than one vocabulary (as namespaces are
designed to allow), then the use of each of those
vocabularies should be validatable according to its own
syntactic and semantic constraints.  This is what
architectural forms can do -- and are already doing -- for
XML resources.  Namespaces (at least the bulk of their
syntax and the idea of identifying a namespace via a URI)
could also be used to do architectural forms.

The alternative SGML syntax for doing architectural forms
works perfectly in XML.  I demonstrated that fact at my talk
at XTech 99 (http://www.hytime.org/papers/srnXTech99/).  I
also offered to share our version of SP (including sx and
sgmlnorm) that reads and processes the alternative PI-based
syntax for architectural form declaration that was adopted
over a year ago by the ISO, mostly for the benefit of XML
users.  My offer stands; the catch is that this small change
to the underlying SP parser hasn't been fully integrated
with SP's error-reporting mechanisms yet.  Some
public-spirited person is welcome to that task.  Takers?
(Anyway, the real issue is what XML parsers will do with
inherited information architectures, not what SGML/XML
parsers like SP will do with them.  What SGML/XML parsers do
has been decided long since, and James Clark's free SP
parser already implements the architectural forms paradigm
very effectively indeed.)

I often hear about how inheritance will be supported by
future "schema languages" for XML documents.  The
architectural forms paradigm (regardless of the syntax used
to exploit it) is, at the very least, a major part of the
solution.  If one doesn't yet understand how each inherited
architecture results in one or two distinct groves (in
addition to the primary XML grove), all cross-connected,
then one doesn't yet "get" it.  Everything in my experience
convinces me that, when one does "get" it, the simplicity
and elegance of the whole thing, taken together, makes its
adoption a no-brainer.  "The solution, once found, is
obvious."  I would strongly urge that the syntax of
vocabulary inheritance in XML be designed *after* the
architectural forms paradigm is well understood, and *after*
there is consensus about how much of it to adopt and exploit
in XML.

In any case, the importance of being able to validate every
XML resource's the use of every inherited vocabulary, on
that vocabulary's own terms, cannot be overemphasized.  If
one accepts the principle that such validation is essential
for reliable information interchange, then I believe the
whole architectural forms thing follows inexorably, groves
and all.

-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

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