Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Schemas as Promises and Expectations
 "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 
|
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
|
|||||||||
