Lists Home |
Date Index |
- From: Leigh Dodds <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 16 Nov 1999 14:18:20 -0000
> I believe that Michael Champion has it right: the behavior of an
> XML processor (and not just an SML processor) must be to 'fall forward'.
> Particularly in e-commerce, the salient criterion will be what the
> processor can *do* (i.e., what processing it is capable of performing, in
> service of its own particular interests) with whatever data, or subset of
> that data, it might be presented with by a particular XML document.
I'd have said an e-commerce app would have been an all or nothing
Transactions should be atomic.
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
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?
> To do no processing of otherwise usable data because some detail of a
> document fails to meet a pre-defined criterion is to fail to do the very
> --processing--which a processor is expected to do in support of
> function at the receiving node.
What if that detail is the whole point of the transaction? What useful
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
determine which bits of data are relevant/fail-safe?
If some 'detail' is irrevelant then why is it being sent in the first place?
You can therefore prune your protocol further.
All or nothing is at least safe.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)