"Bullard, Claude L (Len)" wrote:

>  My problem with pipelines, particularly ones that use transformation, is
>  that someone has to sit down and solve the "gossip chain" problem.  That
>  is, small semantic errors that creep into the maps.  As much as we may
>  say XML is devoid of intent,
>  a chained process isn't.   That is why so much is made of strong semantic
>  types; send this; return that.  Know a priori
>  what this and that are.   Functional, yes, but entirely practical.

But 'errors' from whose point of view? This is precisely the criterion on
which I would distinguish the atomicity of a process: if it requires an
external check or control--validation, or whatever--to determine that it
has returned an 'expected' outcome then it is not the autonomous process on
which a loosely-coupled architecture is predicated. We take it as axiomatic
that a process instantiates a particular input data structure on which it
is capable of operating and that it returns a particular output. The
fundamental distinction between loosely-coupled and monolithic
architectures is that the monolithic model requires shared semantics on
both ends. At the input side to process there is shared intent, generally
expressed in an interface conveying the promise that a particular outcome
will result from the submission of a particular input. At the output side
the shared intent is the promise that the output returned will validate
against a content model or other schematic known a priori. It is only
because of these shared semantics at both ends that such processes can be
tightly coupled into 'pipelines'--really monolithic process chains--which
reliably pass the agreed semantics of one output into the agreed semantics
of the next input.

The loosely-coupled architecture really is different. Here, the
reliability, or predictability, or the preservation of intent extends no
further than a single process and is in fact only internal to that process.
At the input side, one or more documents are presented or are fetched by
the process. As documents, they express no intent precisely because they
are not processes and therefore by their nature have no mechanism to
elaborate intent through function. Even if they attempt to influence
process through PIs or the like, it is not the document which dictates or
is responsible for the form in which it is instantiated for processing
because the process is autonomous in the instantiation of its data and is
beholden neither to instructions from a document nor to shared semantics in
determining the data structures on which it operates internally. Likewise
on the output side the process produces what its particular expertise
dictates is the appropriate outcome. That process is not obliged to defer
to the semantic expectations (of what?--there may be many other processes
interested in this outcome, for many very different reasons) of external
controls either upstream or downstream of that process.

This looselycoupled architecture results not in linear pipelines of process
but in webs of outcome. At each of the interstices of such a web is a
document--a body of syntax--which of itself neither bears semantics nor
expresses intent. For intents of their own--and to elaborate their own
particular semantics--various processes may operate upon each such
document. The operation of each such process should result in an expert
outcome. But because that outcome is expresses in a document, it conveys no
intent to, and exerts no control over, the subsequent processes which might
operate upon it.

Respectfully,

Walter Perry


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>