xml-dev - Re: Architectural Forms and XAF

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

> >AFs provide a paradigm in which, *precisely because AF transformations
> >are so bloody limited in their transformational power*, everybody gets
> >to control their own DTDs, and, at the same time, everybody's messages
> >are interpretable and validatable as industry-standard messages.
> 
> I don't follow this. You seem to be saying that the limimitations on
> AF transformation power somehow helps. Please explain.

After you have transformed a document by means of an *arbitrary*
transformation process (such as an XSLT-driven, DSSSL-driven, or
program-driven transformation process), you can't necessarily tell
whether some particular information set was present in the
untransformed document.  The transformation process is always suspect:
does it respond appropriately to all of the possible information
configurations?  Are all of the possible input configurations
accounted for?  The input document is also suspect: did it really have
the information set I was looking for in the output of my
transformation process?  (No transformation process can correct all
possible malformations in the input.)  When information interchange
fails, and when information interchange depends on transformation
processes of arbitrary capabilities, it's practically impossible to
point the finger of blame at the party whose software was actually
responsible for the failure.  If we can't point the finger of blame,
we can't have reliable, vendor-neutral information interchange.
Accountability is vital.

The essential thing that enables vendor-neutral information
interchange is conformance to rigorous formal models.  Such models are
like contracts between information producers and software producers.
Nobody can write software that understands just any old way of
constructing data; it's impossible.  Models are essential.
I think you agree with this.

On the other hand, diversified industrial communities cannot be
expected to make all their business messages absolutely conform to a
given model.  I think you agree with this point, too.  Your answer
appears to be to provide transformation programs between the variant
dialects used to express a given information set.

I'm saying that your approach will work for a while, but it will
become a black hole for resources and it will be unreliable.  Firstly,
information interchange is not well served by the necessity of writing
so many transformation programs; such programs are costly to create
and maintain.  Secondly, transformation programs contain errors which
are practically impossible to discover and fix in advance of the time
when they hurt somebody.  So, right at the outset, we will lose
information, which will give XML a bad name, and will make rigid old
EDI look good by comparison.  Thirdly, transformation programs are
brittle; they generally require maintenance (which introduces more
errors) whenever something changes.  We've just been through the
costly mess caused by the Y2K bug; does any serious business manager
really welcome the idea of revising a huge amount of
business-model-specific code every time his industry must, as a whole,
deal with some involuntary change in the business climate, such as a
change the governing legislation?  I think not.

Architectural forms provide a reasonable solution to all of
constraints that reality imposes on the problem of supporting
reliable, vendor-neutral information interchange.  I'd be delighted if
anyone comes up with a better solution than architectural forms.
Throwing a welter of transformation programs at the problem is
decidedly *not* a better solution, from a purely economic perspective,
from a reliability perspective, and from a "marketability of XML"
perspective.  Failure to adopt the architectural forms paradigm also
condemns us all to a world in which vocabulary-specific semantic
engines cannot mature into reliability by virtue of their ability to
serve diverse markets.  This would be perhaps the biggest single blow
to the future reliability of vendor-neutral information interchange.

Of course, if we're willing to accept the idea that a single company
will be responsible for the reliability of all information interchange
between everybody, we don't need to worry about the above-described
triangle of constraints (the need for rigorous models, the need to
support diversity, and the need to cope with constant change at the
lowest possible cost).  But then we'd have other problems to worry
about, and there would be no need for XML or other industry standards
at all, would there?

-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/
***************************************************************************