Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Schemas as Promises and Expectations
 Allow me to point out to the members of this list that a concrete example of a general-purpose XML processing tool designed around a clear separation between the producer's and the consumer's interpretation of the data (structures, constraints, algebras) already exists in the field of data bindings where, to use the terminology advanced in this thread, the 'consumer's schema language' is the very type system of the host language. In particular, SNAQue (http://www.cis.strath.ac.uk/research/snaque/) is a research prototype that allows consumers to specify the required interpretation of the data using the type system of the host language and to then tentatively project that interpretation onto the data coming to binding, regardless of the potential availability of a schema (and thus the manifestation of the producer's interpretation) associated with the latter. If there is at least a subset of the data which is described by the projected type, then that subset is injected into the language as a value of the type before being subject of application-specific computation. If not, notification of the failure is communicated to the binding program where it may be dealt with a heuristics-based strategy based on successive type projections (perhaps based on a history of similar failures). Of course, the definition of types to be projected could well be informed by the availability of a schema published by the producer of the data and perhaps capturing the interpretation of a sufficiently cohesive community. Such schema, however, would serve as a convention rather than a rule and would not participate at all in the mechanical process of binding. By reflecting the consumer's interpretation of the data In particular, type projections naturally introduce *partiality* in the binding, whereby the part of the external input which is outside the consumer's interpretation of the data, and thus does not match the projected type, is simply discarded rather than forced upon domain-specific computations. Now, while default projection rules insulate consumers for change to the irrelevant part of their external input they still require that the relevant part of that input be sufficiently in sync with the projected type. Customised projection rules (based on the definition of a mapping between projected types and data expected for binding) may then be introduced to increase the degree of separation between consumer's and producer's interpretation (and thus that or resilience to change) whilst largely remaining in the familiar processing model of the host language. If finally consuming applications must exhibit the kind of adaptive behaviour required by very loosely-coupled internetworked systems then they may need a surrounding full-fledged transformation layer (e.g. based on XSLT or Xquery) to reconcile inputs which resist community-wide conventions and assume related but different forms. In slightly less anarchic scenarios, however, type-based filtering and is sufficient and gives you the advantage of insulating programmers from technologies and maintenance tasks which are largely irrelevant to the nature of the application (a Java programmer does not need to know XSLT, for example). Regards, Fabio Simeoni -----Original Message----- From: W. E. Perry [mailto:wperry@f...] Sent: 09 March 2003 07:07 To: XML DEV Subject: 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 ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl> 
|
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
|
|||||||||
