Re: Empty elements (and processing without a DTD)

>Pro:  solves the problem, for XML parsers which parse the source
>themselves.
>
>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/

Received on Thursday, 12 September 1996 14:09:28 UTC