[
Lists Home |
Date Index |
Thread Index
]
Rick Jelliffe wrote:
> Another aspect is that when importing data into a pre-existing application, the
> application typically has its own validation. So after the gross error-checking
> of WFness, there may only be a fairly narrow range of errors that are not, in
> effect, caught. The interesting question for schemas is, what kinds of errors are
> these and which validation language can express them?
>
> Following that view, the role of XML validation at the receiving end is to check
> constraints that the application does not check (or does not want to). For
> example, a bank may adopt some standard DTD but have its own profile of it,
> selecting the elements that are relevant. The function of validation in that case
> is as a filter: to check that the incoming document does not have excluded
> elements or has the required fields, but not to be concerned with validating the
> data that is allowed.
I agree with you that a well-designed autonomous application certainly might behave
in this manner and thus appear to 'do both' validation of input (or of some portion
of input) against an agreed schema while also instantiating and testing data to
private internal standards. However, one imperative or the other drives the
application; it cannot be both. Either the schematic 'contract' between the parties
interchanging a document is paramount, or an application's implementation of
particular expertise, including expertise in data collection, is. The first case
appears to me to be the widespread XML orthodoxy. Worse, it seems to have led too
many to confuse the executing application's view of input with the view of whoever
supplies that input. This is the difference between understanding that an
application will execute iff the data presented to it meets an agreed standard, and
the expectation that an application must execute when it is invoked with an agreed
data structure.
Philosophically and aesthetically the difference between those two premises is
breathtakingly large, but in the practice of implementing XML-consuming applications
that vast gulf seems to be blithely crossed in many, if not most, cases--all in the
name of respecting the 'contract' for the sake of preserving 'interoperability'.
This is, of course, not interoperability; it is the subordination of a downstream
application to the control of an upstream one. A 'pipeline' of such successively
dominant application is not a pipeline at all; it is at best a chain of command. It
is less interesting and less valuable than a true pipeline because it fails to
harness the specific expertise of each successive process, which much necessarily
include expertise in selecting which data to work on, and how, regardless of what is
presented.
Philosophy and aesthetics can, however, save us from this error when we realize that
the topology for which we should be building these applications is not a linear
sequence of successively dominant applications, but a web of autonomous ones. There
may be many applications with an interest in--which is to say, a use for--the output
of any particular application. The application producing that output might be
entirely unaware of some of these 'downstream' processes. Not knowing of them, it
cannot produce output specifically intended as their input, and it certainly cannot
exercise control over their execution. Instead, it can only produce, in the best
case, the most expert outcome of its particular processing. The 'contract' is then
that it does produce such output and publish it where that data is Web-accessible to
other applications with an interest. How those applications go about selecting and
instantiating that data for their own purposes is in turn private to each
application and is based on the internal data structure around which each such
application is built. It is only the output--not some contractual form of
input--which makes each of those applications of interest and which, when published
in a Web-accessible way, is the basis on ongoing interoperability with still further
applications.
Respectfully,
Walter Perry
|
