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

Re: SD1 - Short End Tags

From: Arjun Ray <aray@q2.net>
Date: Fri, 16 May 1997 23:30:17 -0400 (EDT)
To: w3c-sgml-wg@w3.org
Message-ID: <Pine.LNX.3.95.970516223507.14234A-100000@q2.net>

On Fri, 16 May 1997, Jon Bosak wrote:

> [Arjun Ray:]
> | AIUI, 
> Is that an utterance or an acronym?

As I Understand It, it's 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.

Basically, I agree. But I'm prepared to be less than doctrinaire about
options per se. It actually boils down to the "simple and strong rules"
argument: options with byzantine ramifications are bad. 

> | 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. [cri de coeur of the Desperate Perl Hacker]  
> 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.

Hey, I got assured the first time *I* had to do something like that:-)

In fact, that was the day I realized the general *lack* of "casual" SGML
utilities. Cf the Perl packages for HTML:-(

> 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.

Which I believe I argued would most likely come to fruition the easier it
were to develop such tools/add-ons. Simple And Strong, yet again, this
time argued by negation: if the rules aren't S&S, we won't see these
useful thingies here there and everywhere. The DPH's problem carries a
very important lesson, IMHO, about language design.

> 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.

Yup. Allowing both forms actually opens the door for OMITTAG to be
reconsidered also...

Received on Friday, 16 May 1997 23:25:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:26 UTC