xml-dev - Re: Architectural Forms and XAF

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

[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

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************