Architectural Forms and XAF
From: "Steven R. Newcomb" <firstname.lastname@example.org>
Subject: Re: Architectural Forms and XAF
Date: Thu, 24 Feb 2000 03:51:30 -0600
> > On a related topic, I'm also wondering about the health of AF -
> > where does it stand now? I see a ISO/IEC 10744 document about it, a
> > mention of XAF on Hytime.org, and a XAF site, but little else...
> It's pretty-much dead in the water for now -- almost nobody uses AFs
> or even bothers to defend them who wasn't part of the original DSSSL
> or HyTime design process. It's a shame, because they were a nice
I think any obituary for architectural forms (AFs) is premature, to
say the very least. (David, you're pushing my buttons!)
* The XML Mortgage Partners architecture is based on AFs. Last month
it was adopted by the Mortgage Bankers Association of America. It's
hard to imagine how more money could be depending on AFs. Through
Fannie Mae and Freddie Mac, the mortgage banking industry holds the
keys to the US treasury. The mortgage industry is large, complex,
diverse, and constantly changing, so it's a showcase for the power
of architectural forms as tools for keeping communications between
business partners open, flexible, and yet completely and
demonstrably reliable and independent of any one software vendor.
* Several enterprise-internal systems are based on AFs. These
enterprises are more competitive as a result. Most of them are not
advertising the fact that they are using AFs. I leave it as an
exercise for the reader to figure out why they are keeping it a
* The "Kona" HL-7 architecture was based on AFs. It's hard to see how
the problem of interchanging medical records can be addressed in any
other really practical way, and still remain vendor-neutral.
* The current XLink spec, as revised, is very, very close to being an
inheritable architecture. In fact, I can't think of any way it's
not actually an inheritable architecture, except for the fact that
the spec doesn't declare it in a way that anticipates and
facilitates its use as one among many other inheritable
architectures. Even so, just as in the ISO standard AF paradigm,
the attributes do all the work, and, in practice, the actual tag
names of XLink elements are irrelevant to the processability of
their XLink-ishness. (The creation of the XLink spec is thus a
repetition of the history of the creation of the linking facilities
of the HyTime architecture: the need to make many kinds of links,
even while they must all be reliably processable as XLinks, has once
again inevitably led to the reinvention of AFs.)
* The Topic Maps spec, which seems to be newsworthy these days, is an
inheritable architecture. It's good that XLink has turned out to be
a set of architectural forms, because XML Topic Maps (among many
other applications) must inherit the extended XLink syntax and
When business communities wake up to the fact that they must choose
(1) using AFs
(2) de facto ownership and control of their industry's B2B vocabulary
by a single software vendor,
... AFs will be the rule, rather than the exception. AFs are, quite
simply, the object-oriented way of supporting reliable, vendor-neutral
information interchange. There is just no avoiding the object
oriented paradigm; it offers too many advantages, and it saves too
much money. In the long run, there is also no avoiding the
requirement of industries to control the nature of their own
lifeblood: the information that flows between business partners.
The concept of AFs is not inherently bound to particular formalisms
and syntaxes, although the only standard syntaxes (there are presently
two, one for SGML and one for XML) are bound to the DTD formalism.
AFs are all about hijacking arbitrary models of interchangeable
information, using such models in an unbounded number of contexts,
specializing them in validatable ways, mixing them together in
arbitrary ways, and supporting them via re-usable engines. An XML
Schema can as easily be hijacked as a DTD, even though XML Schemas are
not designed to support that. For that matter, the DTD formalism
wasn't designed to support AFs either, but all inheritable
architectures are today formally expressed as DTDs. Indeed, many DTDs
are being inherited without the knowledge or permission of their
owners, much less any formal indication in the DTDs themselves that
such hijacking is possible. Similarly, there is no way to prevent an
XML Schema from being hijacked and used as an integrated set of
architectural forms, any use of which can be validated against the
constraints of that XML schema.
Monopolistic software vendors hate AFs; AFs are inimical to their
business models. If you only look at information that emanates from
sources that are controlled by the software industry, such as the W3C,
you won't find any mention of AFs. Indeed, the W3C leadership
actively suppresses the AF paradigm, sometimes referring to a similar
but less rigorous and reliable notion as "element templates". Thus,
one could easily get the idea that AFs are dead. Indeed, there are
quite a few people who would *like* the AF idea to go away, but in
fact the applications of AFs are growing, and, from where I sit, it
appears to me that the rate of the increase is growing, too.
I often urge people who are interested in learning more about AFs to
read chapters 9-11 of David Megginson's excellent book:
Megginson, David. Structuring XML Documents. Charles F. Goldfarb
Series on Open Information Management. [Subseries:] The Definitive
XML Series from Charles F. Goldfarb. Upper Saddle River, NJ:
Prentice Hall PTR, [March] 1998. Extent: xxxviii + 425 pages,
CDROM. ISBN: 0-13-642299-3. Price: US $39.95.
Steven R. Newcomb, President, TechnoTeacher, Inc.
email@example.com http://www.techno.com ftp.techno.com
voice: +1 972 517 7954
fax +1 972 517 4571
7101 Chase Oaks Boulevard
Plano, Texas 75025 USA
From: Lars Marius Garshol firstname.lastname@example.org
To: xml-dev email@example.com
Subject: Re: Architectural Forms and XAF
* David Wang
| Thus, I wonder if there are other tools out there that are AF-aware,
| or is there an inherent reason in the dearth of such tools?
* David Megginson
| James Clark's C++ SP SGML library is AF-aware, and it can be made to
| work with XML.
There is also Geir Ove Grønmo's xmlarch, written in Python as a SAX
filter, which as far as I know is the most complete implementation.
Prepared by Robin Cover for the The XML Cover Pages archive. See also "Architectural Forms and SGML/XML Architectures."