xml-dev - RE: Feeler for SML (Simple Markup Language)

[Leigh Dodds <ldodds@ingenta.com>]

> 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
receiving
> processor can *do* (i.e., what processing it is capable of performing, in
the
> 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
application.
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
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?

> To do no processing of otherwise usable data because some detail of a
received
> document fails to meet a pre-defined criterion is to fail to do the very
thing
> --processing--which a processor is expected to do in support of
locally-defined
> function at the receiving node.

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?
You can therefore prune your protocol further.

All or nothing is at least safe.

L.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)