W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > May 1997

Re: SD1 - Short End Tags

From: Jon Bosak <bosak@atlantic-83.Eng.Sun.COM>
Date: Fri, 16 May 1997 15:36:40 -0700
Message-Id: <199705162236.PAA15808@boethius.eng.sun.com>
To: w3c-sgml-wg@w3.org
[Arjun Ray:]

| On Fri, 16 May 1997, Dave Hollander wrote:
| > I am shocked; there have been no postings about this proposal. 
| 8 months ago, I was one of the few who argued for empty end-tags. The ERB
| decided otherwise. 
| AIUI, 

Is that an utterance or an acronym?

| the decision was cast as an exclusive choice, in the interest of
| avoiding option alternatives. So, basically it was empty end-tags either
| everywhere, period, or nowhere, period.

Yes, and the fact that this is to be an option is possibly what
worries me most about it.

| Parenthetically, back then an argument that seemed to carry some weight
| was that relatively casual greppers (e.g. ad hoc perl scripts) would
| benefit from GIs in endtags.  

Right.  I represented a constituency that I personified in the
Desperate Perl Hacker, who is routinely given a job like, "We've just
been bought by FooTech, so change all occurrences of BarGraf to
FooGraf in every one of these 5,000 documents and republish them by
this afternoon, but not if BarGraf is in one of the 13,000 instances
we've embedded in part numbers, just in the 9,000 places where it
appears in a product name."  This is a ten-minute job for a few lines
of perl, but only if *all* product names begin with <product> and end
with </product> and *all* part numbers begin with <pn> and end with
</pn> (or whatever).  Otherwise you have to actually build a parser,
because the obvious simple pattern matches will trip over possible

By the way, I assume that your use of the word "casual" was meant as a
technical description of the script and not a characterization of the
problem.  I can assure you that the problem is far from casual for the
person who is handed this kind of task.

| > I really like it if those building parsers have no problems with it.
| I can't imagine it would pose a problem.

There was never any question that this posed a problem for parser
writers.  It was the users that we were concerned about.

I am as certain as ever that the DPH is a very important constituency
with a very important problem.  We *must* not make it difficult to
solve this problem.  The one thing that might make me change my mind
about this would be the actual (not potential) universal availabiliy
of parsers for the trivial text grammar in every OS, Jade release,
emacs version, perl library, and so on.  If the DPH could rely on the
existence of a function built into every text-hacking tool that would
allow a pattern match to be applied to a given element without
worrying about its possible substructure, then we would have a
fundamentally different situation.

| In fact, problems are likely to come from unexpected GIs in endtags (a
| class of "error" in WF actually created by the -lang spec!)

Several of us thought that this was quite a good point back when you
made it.  This is why I'm bothered by the proposal that the </> form
be optional.  If you could make the trivial parser ubiquitous and make
the appearance of the GI in the end tag unnecessary even for the DPH,
then the position that makes sense to me is the one in which *all* end
tags have the short form.

| But I agree, the lack of posts on this proposal (even to heap scorn on
| it:-)) is somewhat surprising.

You should allow a day or so to pass before concluding that people on
a mail list have had a chance to respond to a posting.  I sometimes
feel about email the way that I do about speed reading courses; the
real need is to get people to slow down.  :-)

Received on Friday, 16 May 1997 18:37:16 UTC

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