[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 nature
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
|
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
|