W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > October 1996

Re: B.11 Empty end-tags?

From: Jon Bosak <bosak@atlantic-83.Eng.Sun.COM>
Date: Sat, 12 Oct 1996 21:08:49 -0700
Message-Id: <199610130408.VAA23422@boethius.eng.sun.com>
To: w3c-sgml-wg@w3.org
CC: bosak@atlantic-83.Eng.Sun.COM
| On 16 October 1996, the ERB will vote to decide the following question.
| A straw poll indicates the ERB is leaning to forbidding empty end-tags.
| B.11 Should XML forbid, allow, or require empty end-tags (7.5)?

I said a while ago that I would speak up for the Desperate Perl Hacker
(and others similarly situated).

The DPH strongly desires that XML forbid empty end-tags -- or (as the
DPH would put it), that all end-tags be required to contain the name
of the element being ended.  Yes, this does make the marked up
document a bit longer.  Yes, it does make it a little harder to type
in manually (though it's very easy to imagine a version of emacs that
automatically inserts the named end-tag using logic something like
what it uses to track matching parens).  But I worked for four years
at Novell with SGML in which empty end-tags were forbidden, and it
ain't that bad.  In fact, the named end-tag can be very useful at
times in understanding where you are in a document.

In return for the little extra space, you reap enormous benefits for
the person (and her name is legion) who has to make a quick change to,
or extract information from, a large collection of documents.
Guarantee that all end tags contain the GI, and you enable incredibly
powerful operations to be performed on arbitrarily large collections
of documents from a single Korn shell command line.  Take away that
guarantee, and suddenly you have to maintain a stack.  This may not
sound like much, but to a lot of people in the trenches, especially
people facing deadlines, it's all the difference in the world.  I
suspect that the same is true for people who build cgi-bin scripts and
similar one-off lightweight processors.

Received on Sunday, 13 October 1996 00:10:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:04 UTC