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

["Thomas B. Passin" <tpassin@mitretek.org>]

The latest posts in this thread seem to be talking mainly about external parsed
entities and what subset to use, with a few choice goodies of like nature.  Most
of these issues aren't really limited to the hypothetical users of some "SML".
External parsed entities, for example.  A really inexperienced xml user won't
even know they could be available or what they are good for.  A slightly more
experienced user might try using them.  Then their recipients have all the
problems people have been discussing - it has nothing to do with any small
subset of xml.

On the other hand, people designing message formats for portable phones, etc.,
had better be using some kind of standard, otherwise how do they know if the
other end can understand their messages?  And that standard could surely be an
xml subset with some wrappers or xml-compatible conventions.

So, for SML,  we are really talking some other users who want to "go Lite".  One
of the main issues is robustness - can we keep working even if everything in the
message isn't perfect according to us?  One example that was mentioned recently
is a leading blank line or space in a document.  Some processors barf, others do
ok.  Robustness is one of the things I like about xml - not that is is super
robust but it's quite a bit better than SGML is (speaking as an SGML-impaired
soul, no offense meant), and it's easier to ensure that the elements, etc., are
well-formed.  Having your non-validating parser keep going when there is
something it doesn't know about is robustness, for example.

It seems, then, that the main users who would be interested in some kind of SML,
according to what I've been seeing in this thread, are 1) those who want to dive
into xml and not bother with many of the fine points in the standard, and 2)
those who need a small footprint (or small message size).  These groups do NOT
have the same interests, and probably one "SML" won't work for both of them. For
each of these groups, I think that David Megginson's post on 11/15 is right on
target.  Let's focus on how the footprint can be reduced (i.e., smaller error
message tables, etc.), and on how to increase robustness for document fragments,
etc.

Tom Passin

From: Simon St.Laurent <simonstl@simonstl.com>


>At 10:46 AM 11/15/99 -0800, Tim Bray wrote:
>>>>Hmm.... just specify the use of a nonvalidating processor.  These have the
>>>>right to ignore external entities, not to barf, just to ignore them.
>>>
>>>Nope, sorry, not that easy, unless you ...
>>>put big warning labels throughout indicating that external
>>>entities should not be used.
>>
>>Right, that's it exactly.  Even if you happen to be using a processor
>>that might try to resolve them.  Sorry, I just don't see this as a big deal.
>
>Try explaining this glitch to people who don't understand XML well enough
>to understand what an 'external entity' is a few hundred times, and perhaps
>your opinion of its importance will change.  The guy who used '&mycompany;'
>may know what it means, but the lucky troubleshooter on the other end may
>well not know - and probably shouldn't have to know.
>
>We're probably stuck with the mess, but unfortunately it's a very big deal
>to certain classes of users, particularly those who'd like XML application
>to process XML documents without a lot of oversight about 'what XML really
>is'.
>
>Simon St.Laurent



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)