Re: Empty elements (and processing without a DTD)

>Pro:  solves the problem, for XML parsers which parse the source
>Con:  many of us have trained ourselves to hate and despise NET, and
>recoil in horror at the prospect of finding useful work for it to do.
>More seriously, it's hard to imagine just how to tell existing SGML
>software how to emit a legal XML document using this mechanism, which
>means every time I touch my XML documents with an SGML tool, I am
>punished by being required to run a little cleanup filter.  The
>distinction between <blort></blort> and <blort/ is also lost if one uses
>an sgmls-style front end.

Such a filter is no worse than the one you would have to write to remove the
end-tags from XML-EMPTY elements before sending them to a validating SGML
tool! You can't win with either approach, but I like the use of NET here
much better than the use of a (to me) unnecessary end-tag. Is keeping a list
of empty elements that you skip over the end-tag processing rules for such a
big deal for parser developers?

As for telling an exisitingSGML parser how to emit XML, simply set the -x
switch on Jade-lite and it will generate XML rather than RTF (if James
accepts this as a useful transformation!) or put in a <?Convert-to XML>
processing instruction *before* the base document element.

>If there's no DTD to read, then there are no EMPTY elements.  Period.

This I like!

>7 Cooked Bits.  A variant of the Raw Bits (parse it and like it!)
>approach would be to provide a different syntax for the declarations, to
>make them really, really easy to parse.

Bang goes any chance of being able to use SGML tools to generate XML!
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK 
Phone/Fax: +44 1452 714029   WWW home page: http://www.u-net.com/~sgml/