[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: A multi-step approach on defining object-oriented
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|