Feeler for SML (Simple Markup Language)

[Matthew Gertner]

Michael Champion wrote:
> 1 - I'd like to see an activity not unlike the one that defined SAX a couple
> of years ago collaboratively researching what a minimal subset of XML and/or
> the DOM  for high-performance and/or small footprint processors might look
> like.  This would entail some actual code experiments to see if there really
> is a significant decrease in processing time or code footprint by throwing
> out support for these features.  If there's no empirically demonstratable
> gain, I for one don't want to continue the pain of this discussion.

I guess there's no harm in looking into this, but this seems like a road
to nowhere to me. On the one hand, it implies a serious risk of
unnecessary confusion because the differences between XML and the
putative SML will be too subtle for non-XML freaks to grog. On the other
hand, any compromise that is found is going to lead to inevitable
satisfaction, with some people feeling that too much was eliminated
while others feel that too much was left in.

> 2 - Assuming for the moment that a gain can be demonstrated, I'd like to see
> a mechanism in XML itself to allow XML messages, documents, etc. to specify
> that they use only some defined subset of features. In other words, I'd like
> to see some built-in mechanism for "bifurcating" XML without descending into
> the chaos of non-interoperability.

This is starting to sound like a pretty good idea. I imagine something
like the SGML declaration but specific to a given schema, rather than a
specific instance. This would enable a schema developer to say, for
example, that PIs, external parsed entities (or my preferences, any
entities), attributes, etc. are not usable with the schema in question.
This is something that the schema WG could add to the current spec with
very little effort. Simon posted something about having done some work
in this direction, but I can't connect to his site right now. In any
case, I'll happily write a short proposal if no one else wants to; it
should only be about an hour's work.

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

Matthew

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)