Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The general XML processing problem
 Patrick Durusau writes: > Curious that the tree syntax of XML (at least if you have "well-formed" > XML) is not seen as a processing requirement. You can process > non-"well-formed" XML documents via SAX (or your MOE) that simply ducks > the question of why require the tree syntax for validity in the first > place? Isn't that a processing requirement as well? Simon St.Laurent writes: > I'll be talking more about Ool (and about Ted Nelson's ideas which got me > started that direction) at the Extreme Markup conference in Montreal next > month. I think you'll be there, and I'll be posting the presentation on > my site in any event. Since we're touting Extreme Markup (with good reason; it's an excellent conference), I too will be speaking on (gasp!--sorry, Len) "Separate Presentation From Content: But How To Distinguish Them?" Patrick has spent years working with the problems of processing multiple hierarchies of markup applied to the same document. Simon has recently revisited Ted Nelson's never-very-popular argument "Embedded Markup Considered Harmful." Both Simon's and Patrick's work have helped me enormously in understanding, and in demonstrating, that finding the line between content and presentation turns out to be the definitive test in distinguishing data from process and in fact in accurately defining each of them. So, no, XML syntax is not by nature a tree, and rendering it as a tree is not inherently a requirement of processing XML. On the other hand, a process intended to render such a tree is entitled to operate on any XML document, regardless of how that document might insist (through PIs or otherwise) that it is not tree-shaped. The question of whether the operation of that process against that document is worthwhile is not for that process to decide. The process executes and renders an output. In a properly loosely-coupled architecture that output will then be made accessible to other processes which might have an interest in it. By the nature of the architecture, the document has expressed no intent, but by its execution the process has carried out intent, to the concrete conclusion instantiated in the output. The influence of a document on the further course of processing and on the outcome of processing ends at the point at which the process to which that document is submitted instantiates the input data which it requires for its own purposes. The influence of that process end, in turn, at the moment it renders its output as a document. So it continues, document triggering process and process rendering document. Rather than a pipeline--in the sense of a single line of process which might be monolithic and perhaps externally controlled by a single intent--this architecture favors a web of outcomes. For every document produced, there are, or may be, a number of processes, each with an interest in that document and each rendering a further document as its outcome. In such an architecture the control--the manifestation of intent--is in the selection and instantiation of the data input to each process. That control must be in the hands of the specific process precisely because only that process knows itself well enough to instantiate its exact data requirements. Yet once that process has completed, its outcome is again a document, which conveys no intent. That document may, however, serve multiple intents as it is selected by various processes, each for its own purposes, and then variously instantiated in the data input required by each. 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
|
|||||||||
