[
Lists Home |
Date Index |
Thread Index
]
"Anthony B. Coates" wrote:
> I guess I'm somewhat familiar with this argument of yours now, but a
> couple of things escape me. One is why this is an *XML* problem. I don't
> see that the arguments apply differently to XML than to binary formats or
> other textual
> formats.
Hi Tony.
It is an XML problem to the extent that XML is increasingly perceived as,
somehow, the basis of 'interoperability'. The nature of any interoperability
achieved depends, however, on how the processes which are supposed to
interoperate are implemented. If the XML which is used for interprocess
communication is understood as documents--and processes are implemented on
the necessary implications of that premise--then there is a basis for
transactional interoperability of those processes, though it is through a
novel mechanism which doesn't look much like two-phase commit. On the other
hand, most (by far, sadly) of the designs we see for processes
interoperating through producing and consuming XML make either (or
occasionally both) the unfortunate assumptions that:
1) XML is the serialization of some object or some data structure,
though an XML instance is in fact a document and the relationship of
document (even adhering to a strict content model or schematic) to
instantiated data structure adhering to the same content model or schematic
is inherently many-to-many. At the point at which that relationship is
constrained to be one-to-one, we have no longer a document but the
fully-instantiated data structure itself--i.e., no perceptible
'serialization'.
The corollary of this unsuitable assumption is that the generic processing
of an XML instance--i.e., before process control might be handed off to some
specialized application but after basic parsing assures conformance of the
instance's syntax and perhaps its validity wrt some content model or
schematic--should instantiate for the recipient's processing the 'same' data
structure, or the data structure which the document creator 'intended'.
2) An XML instance can be so decorated with type and schematic
annotation that it becomes itself effectively the instantiated data
structure upon which an application process might operate directly. This
would be true of binary formats and, given particular processes, for certain
text formats, but it is never true of an XML document.
> The other thing that escapes me is how the world is supposed to function
> under your approach that you cannot predict how another system will react
> to a document/message/bit-sequence that you send to it.
That's just the point: these are autonomous services. They perform their
own expert processing, part of the expertise of which is knowing what data
to select, where to find it, and how to instantiate it for their own
particular purposes. They are not intended to do another system's bidding,
and most especially not to execute remote procedure calls from another
system nor to react in some expected way when a particular data structure is
presented to them. Such autonomy assures that these services are not
enlisted to produce fraudulent outcomes merely because a public interface is
invoked in correct form. By design, it is not the interfaces, or more
broadly the input requirements of these services which are public, but their
output which is published and may be used by other process whose purpose the
creator of that data knows nothing of.
> I'm guessing that it involves a lot of "out of band" negotiation by
> humans.
Not at all. No. Absolutely not.
> If that is the case, my reply would be that this is what always happens.
Yes, it does, both when designing and when executing processes in precisely
the manner that I am trying to avoid. The point of such negotiation is to
align the output of one process with the input expectations of another,
accomplished by tweaking the form of interprocess communication between
them. By contrast, I am describing a design where the form of one process'
output is specific to the expertise which that process is intended to
express, may well be immutable, and in any case is not decided with
reference to the requirements or expectations of any downstream process, the
purpose or even existence of which the original process might well know
nothing of.
> Schemas/templates/formats get abused, and some human interaction is needed
> to resolve the problem by getting both sides to agree on what is what.
> However, that doesn't make XML/Schemas/etc. bad things. They reduce the
> *amount* of that "out of band" negotiation enormously, and that is not a
> bad result as I see things.
I can't help but feel that you are looking entirely at the input side of a
process, where you regard schemas as a public interface, a sort of contract
of what a process will accept and agree to do something with. Outside of the
enterprise firewall, such 'contracts' which oblige processes to execute in a
certain way when given particular input are simply invitations to fraud. I
am instead looking for the output of a process to be published, in the sense
of being made available at a URI, subject to usual http security, where a
process with an interest in that data might find it. A schema associated
with that document might help a consumer of that data to understand what
that document is on its own term. Such a schema cannot, however, indicate
how a consumer is to instantiate some or al of the content of that
document: any such instantiation is specific to the use which the consumer
makes of the document and to the process by which that use is effected.
Respectfully,
Walter Perry
|
