Status of SML?

[Oren Ben-Kiki]

Rick Jelliffe <ricko at allette.com.au> wrote: (to the XmlDev mailing list. I'm
redirecting this to the SML mailing list - I think this is more
appropriate.)

> XML.COM asked me to write an article on SML: it is now up in
> the  current issue  www.xml.com
>
> I hope it is more conciliatory. During the XML development,
> many people who were antagonistic to SGML got a grudging
> respect for it, and many SGML people who doubted toy languages
> would work shifted their positions too. I expect the same thing
> can happen with SML: it may go in an unexpected direction.

I'd like to respond to the points you raised in the article. They touch on
the issues which have been debated in the SML mailing list in these past few
weeks (not that anything has been settled :-)

> So what areas is an SML suited for?
> Perhaps reverse engineering will give some clue:
>
> * If it is UTF-8 only, it is not practical for
> local use for much non-Western data.

SML should support UTF-16 as well as UTF-8.

> * If it allows other sets but does not allow this
> to be unambiguously labeled, is it not suitable
> for transnational use.

UTF-16 is unambiguously labeled. The first char is FFFE. Otherwise the file
is assumed to be UTF-8.

> * If it does not include PIs, it is not suitable for
> server use (on the evidence that most server-side
> includes use special delimiters for what are in fact PIs).

I could never figure out why <?...?> is better then <pi:.../> - that is, why
PIs are inherently better then simple elements. Perhaps you can give an
example?

> * If it does not include some mechanism for literal text,
> it is not suitable for direct data entry.

The use case you are referring to is writing an SML document by hand - say,
in Notepad? I agree that SML isn't well-suited for that. Then again, XML
isn't, either, since it has done away with SGML CDATA elements (good
riddance!).

As for whether using CDATA sections is easier then escaping characters, this
depends on the editor. Any decent one will automate either form of escaping
for you. And users who do such things presumably use a decent editor.

> * If it does not include syntactic distinction for the
> most common targets of tags (i.e., comments, elements,
> processing instructions, entity references), then people
> must introduce another layer straight away.

I don't see why an element-based solution is worse then a special mechanism
solution. For example, why is an XLink based approach worse then an entity
based one? Likewise for comments (<sml:comment>...</sml:comment>), PIs
(<pi:do-something/>), etc.

> * If it does not have basic attribute defaulting, it must be
> bundled with some transformation language; so it is best
> for recipient systems that know the defaults.

First, this assumes SML supports attributes in the first place. I'm for
that - what you call a "soft reductionist" :-) At any rate, it seems XML
defines "default attributes" as:

If an element does not specify this attribute, the parser will _add_ one
with this value; the "rest of the system" is not aware of the defaults.

On the other hand, I thought a major advantage of XML over SGML was that a
document was processable without a DTD. And yet, DTDs as specified are a
watered-down transformation language. It isn't clear to me how this is
reconciled.

SML simply goes "all the way". No DTDs required, period. Defaults, if any,
reside in "the rest of the system" (e.g., using XSLT) and not in the parser
itself. This is a reasonable choice for a simplified usage profile.

Share & Enjoy,

    Oren Ben-Kiki


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)