Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Schemas as Promises and Expectations
Don Park wrote:
> Using schemas as a contract between two highly independent groups (producers
> and consumers) seems unwieldy because the two groups must walk in sync as the
> schema evolves. What if the contract is divided into two parts, promise and
> expectation? An XML producer's version of the schema promises precisely the
> content and structure of the produced XML documents. An XML consumer's
> version of the schema specifies the content and structure of the XML documents
> the consumer expects. Promises and expectations don't have to match exactly
> to function.
Dividing promise from expectation is a *very* good idea for XML because 1) it
is inherently well suited to the internetwork topology and 2) it is likewise
well suited to the easily extensible nature of XML document forms in the hands
of different authors. But, as you say, once the division is made it is no longer
feasible for producers and consumers to walk in sync regarding the form of
documents which they handle in common. To be precise, it is no longer possible
for interaction or transactions between them to be based on sharing an identical
data structure against which they execute their respective processes. Sharing
such identical structures is the fundamental premise of two-phase commit and,
more broadly, of the past twenty years' experience in transaction processing. In
severing the promise of the producer from the expectation of the consumer we
should be prepared to build a new model for transactions.
The first consequence of the division you propose is that a processing
node--which is both a consumer and a producer of data--will not define its input
interface around the promises of upstream sources, nor its output form around
the expectation of downstream consumers. Presumably one motivation for your
proposal is to allow a node to consume the output of many different producers,
each in somewhat different form, and of other producers as they may become
available. A parallel motivation is presumably to allow the production of any
one node to be consumed by nodes whose particular expectation it does not know,
as well as by nodes which later appear with uses for that production, but whose
expectations couldn't have been known or accommodated when the form of that
output was specified.
This processing model can be realized (it's not all that difficult) with the
recognition that
1) there is no meaningful input interface to a process. This assumption
obviates at a stroke presenting processing as an object, as well as any RPC-like
invocation of process, precisely because this consumer has not published its
particular input expectations, let alone 'contracted' to behave in a specified
way when they are met.
2) the precise output form of a process can always be determined accurately,
at least by any consumer which is authorized access to it. The instance bespeaks
the form. This accords nicely with the REST paradigm: what a consumer GETs
defines the output of the upstream process.
3) the expertise of a processing node is expressed in the transformation of
what is available to consume into a particular form specific to the process
which produces it (rather than conditioned on the 'expectations' of the
'intended' consumers of that product). In order to achieve such an application
of expertise, a processing node must choose what to fetch as input, must
instantiate that data in a form specific to particular process, regardless of
the form in which that data might originally be found, and must express in the
particular form of output the value added by the process performed.
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
|
|||||||||
