[
Lists Home |
Date Index |
Thread Index
]
John Cowan wrote:
> The trouble with "the data instances which they have actually got" is that they may
> represent an undersample of the actual data to be received during the life of the
> application.
Granted. My argument, though, is that an application presented with an ostensible input data
instance need not be concerned at all with the full range of input data which it might be
presented, but only with whether, from this instance, it can instantiate in accord with its
internal data structure the data which it requires to execute a single instance of its
processing.
> An application driven by input data is in the position of a judge attempting to interpret a
> statute: any available information on authorial intent is valuable.
As 'statute' here is analogous to schema, or other a priori agreement or data input contract,
then this is precisely what I am arguing should *not* be the design of autonomous applications
(Web services?) in the internetwork topology. Those applications absolutely should not care
whether they are part of a larger context of agreement (i.e. semantics analogous to authorial
intent) over a schema for input data. The sole concern of the application should be whether
the data as presented in this particular instance meets its internal needs for an instance of
execution of its expertise. Precisely what I am *not* talking about is an 'application driven
by input data', if by that phrase you mean an application committed or expected to execute
because it is presented input data of a particular form. My argument is that XML-consuming
applications 'on the Web' must be designed to be driven by their own private expertise,
including their expertise in data collection and instantiation, which cannot be dictated to
them, either positively or negatively, by the prescription of a particular input form.
> Fundamentally, validation serves one of two purposes: self-consistency and suitability.
> Classic DTDs were designed to provide self-consistency (an instance respects the constraints
> it says it respects) and have nothing to do with suitability.
Agreed, except that what I am talking about are applications designed so that they do not
agree to respect (that is, perform in an expected way upon the presentation of) data instances
respecting particular constraints.
> However, it is also possible to use schemas (including DTDs) as suitability testers, and
> this is the explicit use model of RELAX NG. Here a receiver expresses declaratively a set
> of constraints that would otherwise have to be programmed into its code that restrict the
> sort of input it is willing to deal with. Depending on the overall system, rejected input
> can be sent down a channel or just dropped.
This is indeed admirable, and the premier feature of RELAX NG. Notice, however, that the
receiver, operating as an application instance, performs this constraint testing internally
and may--I argue should--be testing data for suitability to a private standard rather than to
one shared as the putative basis of interoperability.
> This leads to the notion of a Linda system in which one accepts XML documents from the
> Lindasphere based on a RELAX NG schema: documents which match the application-provided
> schema are read (and typically, but not necessarily), removed; other documents persist until
> some other reader accepts them.
Yes, precisely, except that I would argue that documents should rarely, if ever, be removed.
They persist as the interstices of growing webs of reuse by autonomous expert applications.
Respectfully,
Walter Perry
|
