Feeler for SML (Simple Markup Language)

[W. E. Perry]

Matthew Gertner wrote:

> Michael Champion wrote:
> > 3 - I'd like to see some specification or demonstration for how an XML
> > processor that is optimized for a subset of the spec can "barf" on external
> > entities or other unsupported features in a way that would allow it to
> > potentially extract useful information out of the document or message it's
> > processing.  For example, I might (for some reasons of my own) document or
> > "decorate" an XML message with attributes or entities, but when Don Park
> > gets it ;~) , his stripped down processor should be able to extract the
> > "wheat" (simple element values) and ignore the "chaff" (my documentation and
> > decoration). Such a mechanism would have to be much lighter weight than what
> > would be possible with DTDs or schemas.
> > (Again, if it can be demonstrated that something functionally equivalent can
> > be done *efficiently* without mucking with the XML spec, so much the
> > better).
>
> And alternative that is certainly worth considering: the processor
> simply rejects the document if an unsupported feature is used. Since the
> document authors are presumable writing (or the software developers
> generating) an XML instance on the basis of a schema, the onus should be
> on them to respect *all* aspects of the schema definition, including
> supported features. The best thing a processing app can do is reject the
> document out of hand, letting authors know that their implementation is
> faulty and forcing them to fix it immediately before non-conformant
> documents are unleased to wreck havoc. Your approach runs the risk of
> producing behavior that was not expected and might therefore have
> undesirable side-effects (considering the implications for e-commerce,
> among other things).

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. 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.

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)