xml-dev - Re: Feeling good about SML

[Eric Bohlman <ebohlman@netcom.com>]

On Tue, 16 Nov 1999, Sean Mc Grath wrote:

> I think there is a step before SML which -- if it went well --
> might even remove the need for SML:
> 
> 1) Tie down what the bifurcation areas that cause XML
> interoperability problems and allow people to throw
> the phrase "XML parser" around with wild abandon.
> e.g. external subset processing, external entity references,
> Unicode encoding(s) supported, location information, etc. etc.
> 
> For arguments sake, lets call this the XML Feature Manifest
> (XMF).

I think there's a step or two before even that.  We've been talking about
"simplifying" XML without sharing an operational definition of "simpler."
I've seen people interpret in this discussion in at least three senses:

1) Requiring less code to parse.

2) Requiring fewer characters to be transmitted over a communication link.

3) Requiring less time and effort to learn.

These senses are orthogonal; efforts that achieve one may not necessarily
help with the others, and may make matters worse.

I'm not convinced that 1) is even a problem, and I believe people like
David M. when they say that subsetting features would not result in a
substantial footprint reduction for a well-written parser.  I think what
we have here is really an issue of API complexity, but APIs can be
simplified without touching the language itself.

For example, it would be reasonable for a parser to be used in a wireless
device to have very little error-reporting ability; a simple go/no-go
indication would be enough.  Such a parser probably doesn't need
facilities for obtaining the character position of an error or the exact
nature of the error; there's nothing the user of the device would be able
to do with that information anyway.  Therefore, such a parser wouldn't
need to store code for error messages.  Anybody who needed to debug the
data being sent could use a bigger parser on a desktop machine.  Nothing
about XML itself mandates the presence of development-tool hooks in a
parser API, yet the presence or absence of such hooks can make a big
difference in a parser's footprint.

2) can be handled transparently to the language itself.  One can either
use standard general-purpose compression mechanisms, or mechanisms (like
SHORTTAG encoding) that take advantage of the textual properties of the
language.

3) is really a matter of simplifying APIs, not the language itself.  I
don't believe the cognitive load of XML according to the W3C
recommendation is excessively high for a programmer who needs to write
code for generic XML processing.  If a programmer only needs to deal with
a handful of XML applications, the solution is to create
application-specific APIs for those applications.  The user of such APIs
shouldn't have to even be concerned with the fact that the data is going
in and coming out as XML.

To sum it up, before we can decide *how* to simplify XML, we need to
decide *why* we need to, and *if* simplifying the language itself is the
solution.  Otherwise we run the risk of premature closure, constructing a
problem definition based on the characteristics of the perceived solution.



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)