Cover Pages Logo SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic

Architectural Forms and XAF


From:     "Steven R. Newcomb" <srn@techno.com>
To:       david@megginson.com
CC:       xml-dev@xml.org
Subject:  Re: Architectural Forms and XAF
Date:     Thu, 24 Feb 2000 03:51:30 -0600

[David Wang:]
 > > 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...

[David Megginson:]
 > 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
 > idea.


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
   secret.

* 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
   semantics.

When business communities wake up to the fact that they must choose
between ...

(1) using AFs

     or

(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.

-Steve

Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com
voice: +1 972 517 7954
fax    +1 972 517 4571
Suite 211
7101 Chase Oaks Boulevard
Plano, Texas 75025 USA

From: Lars Marius Garshol larsga@garshol.priv.no
To: xml-dev xml-dev@xml.org
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.

[See:]  http://www.infotek.no/~grove/software/xmlarch/xmlarch.html


Prepared by Robin Cover for the The XML Cover Pages archive. See also "Architectural Forms and SGML/XML Architectures."


Globe Image

Document URL: http://xml.coverpages.org/newcombAFs20000224.html