[
Lists Home |
Date Index |
Thread Index
]
"Thomas B. Passin" wrote:
> But I do not think that the consuming node can accept just anything and
> successfully transform it to a preferred form.
Of course not. But to understand how this works it is important to quit thinking
in terms of what the consuming node accepts. I realize that is difficult: the
notion of the public interface, the passed data structure, the call or
invocation of a procedure is pervasive. The point of these procedures is to
offer a specific expertise as a service. A necessary, inevitable part of that
expertise is knowing what to accept as input, how to test its acceptability,
where to find necessary reference and other ancillary data, and how to
instantiate a data structure specific to the processes which will operate on it.
The measurement of success looks beyond the shallow question of whether a
process has been cajoled to execute to the test of whether a useful output has
been produced. That can be answered only by other such processes with their own
particular interests in the output produced by this one. The usefulness of the
output of one process is in whether other processes can in turn render from it
some useful application of their own expertise.
> More important, perhaps, is that the incoming documents have a stable format.
> You can adapt to nearly anything as long as it is consistent.
Indeed you can. In practice I am continually surprised by what unexpected
variations seem sensible in the light of what has come before from the same
provenance or in similar structures. Also, stable does not have to mean static.
Changes make sense as changes, measured against the history of forms encountered
in the past, in cases where the resulting changed form would be unintelligible
if encountered without context.
> So are you arguing for Don's point, which I take to be the following -
>
> A producer should consistently produce according to some definite schema
> (lower-case schema, not just WXS, of course), and a consumer should design
> around using some (possibly different) definite schema, converting as needed.
I cannot speak for Don, of course, but I would change this characterization
slightly to emphasize that an expert service should produce the most particular
expression of its expertise. From the viewpoint of the process that
particularity might in some cases best be described by a schematic of output and
in other cases not. Either way, that output will have a published concrete
instance expression from which a schematic might be deduced if that is useful.
As for consuming processes, every process is designed and implemented to operate
upon an expected data structure. I ask that in recognition of the particular
expertise of a process the data structure instantiated for its internal use be
precisely that on which it natively operates. In both cases, the form of these
input and output data structures may change over time as the specifics of the
process itself dictates. A key point of design here is that such changes a
simply made internal to the service as changes in its process may require,
without the need to coordinate those changes with other processes either
upstream or downstream.
Respectfully,
Walter Perry
|
