Feeler for SML (Simple Markup Language)

[W. E. Perry]

Leigh Dodds wrote:

> I'd have said an e-commerce app would have been an all or nothing application.
> Transactions should be atomic.

Yes, it is precisely the e-commerce *app* which should be all-or-nothing *on its own terms*.
That is, a particular process defined and executed at the receiving node either will, or will
not, have all of the input data it requires. The definition of that data requirement is local:
the sending node supplies data, presumably conforming to a definition which makes sense to the
sender, but is not entitled to specify for the receiver the particular definition either of
the data or of the processes to be performed on it. And, yes, transactions should be atomic
but, again, on their own terms. The atomicity of the transaction is only from the point of
view of the (receiving) node which executes it. From the point of view of the node sending the
data which triggers a remote transaction, the 'atomic' transaction may well include (and in
the execution of trades in securities--the example you use below--nearly always does include)
several such remote pieces.

> If I sent you an e-commerce order, and I've accidentally (or mistakenly) sent you my company
> name in an external entity, what will you do with the order. Buy in the stock, but have
> nowhere to ship/charge it? What if I've incorrectly coded the amount of stock I want - how
> much will you send/charge me?

Let's make these examples real. Execution of orders in securities does not occur in a vacuum.
In order to accept an order to deal on your behalf, or to deal with you as principal, I must
know enough about you to be able to confirm, compare and settle the transaction. It's not
merely that I can't execute the trade if I don't know your company name:  I can't execute it
even with your company name if I do not know your confirmation and settlement details. In
other words, to get to the point where you can send me an order for execution, we have already
gone through significant exchanges of data, to establish the context in which that trade,
legally as well as logistically, might be executed.If after all that you neglect on one
occasion to send your name with the order, then if I know the provenance of the message I
already know who you are, and I can supply the missing data. If the data missing on that
occasion is a crucial detail particular to that trade (see your objections just below) then,
because I know who you are (from context previously established) and know the provenance of
the message you have sent me, I can (programmatically, from my processor) send you a message
requesting the missing details which I require to consummate the transaction.

> What if that detail is the whole point of the transaction? What useful information is left?
> How do you decide how incomplete the document/message/fragment can be before the transaction
> becomes useless? Do you have to apply heuristics to determine which bits of data are
> relevant/fail-safe?
>
> If some 'detail' is irrevelant then why is it being sent in the first place?

Irrelevant to the receiver, and to the processes which the receiver can perform, does not mean
irrelevant to the sender.

> You can therefore prune your protocol further.

Or, my protocol could be to derive the schema on every occasion from the data as actually
received and as instantiated within the context of locally-defined processes which the sender
may know nothing of.

> All or nothing is at least safe.

Unfortunately, it is safely nothing if we cannot process the very transactions which we went
into business to execute.

Respectfully,

Walter Perry



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)