Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: The general XML processing problem
 In the sense that I want to ensure that if I send a RequestForProposal, a Proposal is returned, or am able to inquire that if I send a RequestForProposal, I can get back an answer that says, No, or Yes in a few weeks, or Yes by The Deadline You Specified, or "What is a Proposal and how would we know one if we had it?" I don't mean in the sense that if I call a non-void function, I need to know that a string is returned. One doesn't want to spend eternity trying to trick Schrodinger's Cat, but markup past genCoding has been based on the concept of a document type. It works fairly well when one can discover or be instructed in what types are available given a particular query. len From: W. E. Perry [mailto:wperry@f...] "Bullard, Claude L (Len)" wrote: > My problem with pipelines, particularly ones that use transformation, is > that someone has to sit down and solve the "gossip chain" problem. That > is, small semantic errors that creep into the maps. As much as we may > say XML is devoid of intent, > a chained process isn't. That is why so much is made of strong semantic > types; send this; return that. Know a priori > what this and that are. Functional, yes, but entirely practical. But 'errors' from whose point of view? This is precisely the criterion on which I would distinguish the atomicity of a process: if it requires an external check or control--validation, or whatever--to determine that it has returned an 'expected' outcome then it is not the autonomous process on which a loosely-coupled architecture is predicated. We take it as axiomatic that a process instantiates a particular input data structure on which it is capable of operating and that it returns a particular output. The fundamental distinction between loosely-coupled and monolithic architectures is that the monolithic model requires shared semantics on both ends. At the input side to process there is shared intent, generally expressed in an interface conveying the promise that a particular outcome will result from the submission of a particular input. At the output side the shared intent is the promise that the output returned will validate against a content model or other schematic known a priori. It is only because of these shared semantics at both ends that such processes can be tightly coupled into 'pipelines'--really monolithic process chains--which reliably pass the agreed semantics of one output into the agreed semantics of the next input. The loosely-coupled architecture really is different. Here, the reliability, or predictability, or the preservation of intent extends no further than a single process and is in fact only internal to that process. At the input side, one or more documents are presented or are fetched by the process. As documents, they express no intent precisely because they are not processes and therefore by their nature have no mechanism to elaborate intent through function. Even if they attempt to influence process through PIs or the like, it is not the document which dictates or is responsible for the form in which it is instantiated for processing because the process is autonomous in the instantiation of its data and is beholden neither to instructions from a document nor to shared semantics in determining the data structures on which it operates internally. Likewise on the output side the process produces what its particular expertise dictates is the appropriate outcome. That process is not obliged to defer to the semantic expectations (of what?--there may be many other processes interested in this outcome, for many very different reasons) of external controls either upstream or downstream of that process. This looselycoupled architecture results not in linear pipelines of process but in webs of outcome. At each of the interstices of such a web is a document--a body of syntax--which of itself neither bears semantics nor expresses intent. For intents of their own--and to elaborate their own particular semantics--various processes may operate upon each such document. The operation of each such process should result in an expert outcome. But because that outcome is expresses in a document, it conveys no intent to, and exerts no control over, the subsequent processes which might operate upon it. 
|
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
|
|||||||||
