Re: [xml-dev] Caught napping!

["W. E. Perry" <wperry@fiduciary.com>]

John Cowan wrote:

> No, no.  I was functioning as your supervisor/employer, and telling you to write a process
> that would achieve that goal.  But let that go.

As I say: expecting to issue me a procedure call, or in this broader mandamus, specifying
the form of procedure call to which I was to respond. But, indeed, let that go.

> Okay, fine.  *What* own devices?

Clearly you do expect management control over my behavior. Let's pull our focus here back to
the very big picture, where we can discriminate the form of transactional operation which I
implement from that which you expect. I distinguish the two fundamental transaction
mechanisms as agency and principal. It is clear that your premise (and you are not
alone--transactional software routinely implements the expectation) that if I am a service
or process of use to you, then I am to carry out some procedure on your behalf.

>  How can your process know that John Cowan is a personal name and not the name of a 3rd
> party insurance company?

The short, if rude, answer is that you do not need--and are not entitled--to know what my
process knows, or how, because my process is not your agent. It has taken principal
ownership of data--some of which comes from you and some of which may not--and takes
principal responsibility for how that data might be manipulated in light of what my process,
by its autonomous standards, regards as a useful outcome. I was an interested party to your
original data, though precisely which of that data and why I was interested is not your
prerogative to know. You, in turn, may be an interested party to the output of my process.
Nevertheless, the path from the data which you hand me to the data which I hand back to you
need not--and if I implement the process, almost certainly will not--go via straightforward
processing by your agent, consonant with your expected semantics. The semantics which you
expect are bound to the whole of the data as you understand it:  the original data structure
which you hand me reflects a semantic entity at a granularity which is sensible for your
uses, as you understand them. The semantic entity around which my process is conceived may
be only tangentially related to your expectations.

The practical answer to how my process 'knows' what it needs to know is that it knows more
about 'your' data--within the context that my process uses it--than you do. This is the
essential nature of principal, rather than agency, transactional responsibility. My process
takes the data from you because it knows--and as a process, it is designed to
manipulate--something about that data which is significant in a context which you know
nothing of. The mechanism in which my process engages is, in fact, arbitrage, which is the
perfect expression of the principal transaction process. In a financial arbitrage I can buy
securities from you at slightly more than the going rate in your market, because I know, as
you do not, that I can sell them simultaneously elsewhere at a significantly higher price.
As a principal, rather than agent, processor of data I can take data from you without regard
for what you think it means or how it should be handled because I know where I can find
elsewhere the context which, through the execution of my process, results in the creation of
something of use or profit to me, deriving in part from your original data.

> Even if it can look up such strings in a database, suppose John Cowan is the name of
> *both* a patient *and* an insurance company?  Then what?  Furthermore, all unknown to you,
> the appearance of "John Cowan" here represents the creator of the document format.  Then
> what?

Here you are again supposing how my process operates. The context in which I use the textual
content "John Cowan" which I found in your data instance may be one in which the appearance
of a matching string is by itself significant, regardless of the 'role' (patient, insurance
company, document format creator) which got that matching string into that context in the
first place. I have often designed basic tests for fraud which are *very* interested when a
match turns up in a role where it should not have appeared (payer is also payee, agent is
also principal, etc.). The salient point is, again, that you do not design, control, or even
know the detailed functioning of my process. I realize that those expectations are very
difficult to disabuse yourself of. The agent model of transaction processing is pervasive
and familiar and seems natural. Nevertheless, that agent model can work only when you and I
operate on precisely the same data structure. That implies not only that we have a priori
agreement on the schematic model itself, but that we share sufficient agreement on our
semantic expectations of it to justify to each of us the choices we have accepted for that
data's structure and content. Passed between us in this way, that data is fungible, but only
because of the constraints each of us has accepted which have resulted in our respective
processing being conditioned on precisely the same data structure.

The very different assumption of the principal transaction mechanism is that I can do
something outside the scope of agent processes which may be available to you by virtue of a
priori agreements that you have accepted. I do not offer myself for hire to perform a
service as your agent, but instead offer the product which is the outcome of my processing.
You do not supervise nor employ me, instruct me to create a process, nor dictate how I
should proceed, for I am not your agent. I buy data from you. Perhaps later I will produce
data which is somehow of interest to you, and you will buy it from me, but these remain
entirely separate and barely related transactions. After I have bought data from you a
number of times, I know from experience what to expect of it. I will know if you change its
model, and if you do I will know how such change affects my particular use of it and can
make a precisely informed decision whether it is worth continuing to buy. You, in turn, are
free to change the model in response to your own needs or to respond to someone who is a
better customer for your product than I. In either case you are not obliged to secure my
agreement before making a change.

Why implement transactional processes on this principal model rather than as an agent?
Because there are much greater prospects for business, and for creating new business from
every newly-recognized use for data. The agency model immediately commoditizes the agent's
service, which is saleable only because it is utterly standardized on an agreed input and an
expected outcome. If I work this way, the primary constraint on what I might accomplish with
my process is what you think you *mean* by your data, rather than what I might produce from
it if left to my own devices. And you still will not hire me unless I am the lowest cost
agent, which will be determined by a host of forces exogenous to how much I accomplish in my
process.

This discussion has now veered far from where it began in Linda Grimaldi's speculation on
what it might imply to treat "XML as XML in a very fundamental way" and whether the ability
to persist and manage XML 'natively' might offer new choices for the modeling and
understanding of data, beyond the expectations imposed by the RDBMS and OODBMS models.
Clearly my answer is yes, there are significant new choices. To break free of the schema,
the model, and other a priori expectations and to manage XML on its own terms--instance
first--is the revolution necessary for supplanting the agency model of transaction
processing with the principal mechanism. Twenty years ago DBMS's ostensibly built on the
relational theory became the infrastructure for two-phase commit (agency) transaction
execution. The principal mechanism for transaction execution requires the support of a
history stated in the particular, perhaps unique, terms of each instantiation of data within
the context of a process. That calls for a database engine natively suited to persisting and
manipulating instance-first XML.

Respectfully,

Walter Perry