[
Lists Home |
Date Index |
Thread Index
]
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
|
