[
Lists Home |
Date Index |
Thread Index
]
Not necessarily. Either
a) You are instructed in how SYSTEM XYZ intends to process,
or simply, precisely what it intends to return (the type
commitment - precision is THE question here).
b) You have a way to instruct SYSTEM XYZ with instructions it understands.
Semantics require symbol-grounding, the apriori process of assigning meaning
to signs. XML doesn't care. XML systems can and that level above
the markup where processing occurs does require a system contract and a
system for creating contracts to exchange data and have it processed
by a means to which parties commit in advance through committing to
what is returned or committing to the process. Schemas are a
a way to say "here is what I think you asked for" and the reason
for PUBLIC IDs is to assert that one is obeying a public contract.
We don't have to get wrapped around the existential
issues of whether or not zero is a quantity or simply a notational
convenience. Somewhere, a byte changes state (Goldfarb).
The difficulty is "end to end" or "blind interoperability". I
don't believe that to be possible outside a very narrow system
definition. It is the Schrodinger's Cat problem.
len
-----Original Message-----
From: W. E. Perry [mailto:wperry@fiduciary.com]
Joe English wrote:
> The best answer to the question "How does an XML document indicate how it
> should be processed?" is "It doesn't."
>
> "How does an XML document indicate how it should be processed *in system
> XYZ*?" can be answered by system XYZ.
This is a wonderfully succinct statement of the consequences of data being
autonomous from process. I would love to think that we could say 'Amen' and
leave the matter here at rest. I have, however, reluctantly concluded that
the desire for documents to express authorial intent or preference is simply
too strong and too widely held to be overcome even by repeated demonstration
of the superior usefulness of a simpler, loosely-coupled architecture.
End-to-end enforcement of the narrow intent of an original author pervades
monolithic process designs. XML gives us the opportunity for more versatile,
more reusable, and less brittle processes, but only if we understand,
respect, and enforce the difference between data and instruction.
> (XML 1.0 even defines a handy place to put such instructions -- in an
> <?XYZ ...?> PI -- but for some reason that's considered heretical.)
It is heretical, if it presumes enough a priori knowledge of process XYZ to
be comfortable instructing that process in the execution of its own
functions.
|
