groves dissent (was RE: RFC: Attributes and XML-RPC)

Steven R. Newcomb srn at
Sat Sep 25 06:23:05 BST 1999

[Matthew Gertner:]
> ... HyTime throws out too many hard-to-understand concepts at
> once. The linking model is hard to understand. Groves are hard to
> understand. Architectural forms are hard to understand. Throwing
> these together in a 1000 page document is not a recipe for
> commercial success. It seems to be an unambiguously good thing that
> these concepts are now being split into bite-sized chunks in the
> process of transfering them into an XML context.

I have no choice but to agree with you (and believe me, it has been
difficult for me to stomach this particular reality).  I *would*
rather have it all broken into bite-sized chunks, if that's what it
takes.  I only hope we can put Humpty Dumpty back together again
later.  (By "Humpty Dumpty" I mean the meticulous balance with which
all the concepts of component addressing, re-use, and semantic
assignment fit together seamlessly, consistently, and with minimum
implementational redundancy in the HyTime family of information

Indeed, the problems I have with XML Namespaces all have to do with
the fact that there are ways of using XML Namespaces that will create
unnecessary -- and maybe even insuperable -- difficulties for those
who will have to put Humpty back together again.  XML namespaces, as
presently defined, are widely (and perhaps unconsciously) regarded as
meeting the same requirements that the architectural forms paradigm
(inheritable DTDs) already meets.  Some Very Influential People at W3C
are on public record as believing/expecting XML namespaces to meet the
same requirements that are met by the architectural forms paradigm,
even though the Namespace Rec correctly makes no claims that Namespace
paradigm can meet any of the same requirements that the architectural
forms paradigm meets.

Architectural forms, which are presently formally representable only
via the hoary and suboptimal (but at least standard) DTD syntax, *do*
meet those requirements.  Architectural forms already work perfectly
with XML, as I demonstrated last February at XTech 1999, and as Eliot
Kimber and others described at Metastructures 1999 last August in

In my public speaking lately, I've been urging all my listeners to
pray for the XML Schemas committee, which has a very hard job to do,
and which is trying to do it under circumstances which are, well,
trying.  Although I am not privy to the discussions in that committee,
I detect stronger and stronger linkage between XML Schemas and XML
Namespaces in the information that W3C chooses to publish about that
project.  If XML Schemas only affect XML Namespaces, or if they are
totally dependent on XML Namespaces...  well, I don't like to think
about it.  Many systems and industries will stick with DTDs and
architectural forms, because they work.  Architectural forms allow the
"finger of blame" (for failures of information interchange) to be
pointed, even when there is local control of the DTD, and they allow
all elements and attributes to have any names at all, while still
being automatically recognized as architectural forms.  Anyway, I'm
still hoping that the XML Schemas committee

* will act favorably on its recognition of the importance of being
  able to validate the use of vocabularies in instances,

* will harmonize all the concepts of DTDs, namespaces, and inheritable
  architectures in XML Schemas, creating a single schema syntax that
  will accomplish that goal, so we can say good-bye to DTD syntax at
  last, and start using something much richer, much more convenient,
  and much more helpful in promoting the reliability of information
  interchange in a system-vendor-neutral fashion, and in a
  multi-system-vendor environment.

It may not be easy to design that syntax, but I see no technical
reason why it's not doable.  It's also pretty obvious that the schema
language itself should be formally modeled and expressed in its own
syntax.  (On the way to that goal, some bootstrap problems can be
solved by using the old DTD syntax.)

I believe that Paul Prescod's "Hedge Automata" presentation at
Metastructures 1999 should be well-understood by whoever's trying to
design the long-awaited XML Schemas recommendation.  There is hope
that the formal expressions of architectures (vocabularies) can be
validated for conformance to their base architectures (their inherited
vocabularies).  The ISO architectural forms paradigm only permits
*instances* to be validated against their base architectures
(inherited vocabularies), not *DTDs*.  While this is not a weakness
that diminishes the usefulness of architectural forms, it would be
very nice to be able to validate the formal expressions (such as DTDs
or other schemas) of architectures against the formal expressions of
the architectures that they declare themselves to be based on.  For
example, it would allow people who are trying to design DTDs that
declare themselves to inherit from one or more base architectures to
have a tool that will detect inconsistencies between the DTD that they
are writing, and the base architectures from which they wish to
inherit certain architectural forms.

> (BTW: I have to make a big plug for Paul Prescod's July99 grove
> tutorial. After reading this I *finally* feel like I understand what
> the #%@$! a grove is. Great work Paul! If you are trying to
> understand groves without reading this, don't torture yourself.)

Good advice.  Paul's tutorial can be found at


Steven R. Newcomb, President, TechnoTeacher, Inc.
srn at

voice: +1 972 231 4098
fax    +1 972 994 0087
pager (150 characters max): srn-page at

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list