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

Re: Caveat Tag Salad (Was: some ERB decisions)

From: Arjun Ray <aray@nmds.com>
Date: Sun, 20 Oct 1996 19:04:00 -0400
Message-Id: <1.5.4.32.19961020230400.00369930@www.nmds.com>
To: W3C SGML Working Group <w3c-sgml-wg@w3.org>
At 06:30 PM 10/20/96 GMT, Charles F. Goldfarb wrote:
>On Sun, 20 Oct 1996 02:57:23 -0400, Arjun Ray <aray@nmds.com> wrote:
>
>>Yet, I'd like to point out (at the risk of bothersome repetition) that the
>>*real life* experience of HTML suggests that we ignore the possibility of
>>tag salad at our peril.
>
>>Simply assuming that it's "obvious" people will get their nesting right,
>>when explicit labelling of endtags makes the error particularly
>>*non*-obvious, is *very* unwise, IMHO.
>
>Arjun,
>
>Is it accurate to conclude from your argument that:
>
>1) It would be best to have *only* empty end-tags as that would guarantee
proper
>nesting in all cases (although not necessarily the nesting intended by the
>author).

Yes, that's been my preference all along (see #195 on this list, from Sept 15.) 

I have considerable sympathy for the DPH argument (having done quite a lot
of such quick-and-dirty stuff myself), but it's based on a *historical* lack
of tools, in turn attributable to SGML parsing packages being extremely
non-trivial to develop. In the long run, reliance on the DPH's talents
doesn't bode well for system robustness; nor does ease of ad-hacking strike
me as a particularly meritorious design principle.

In contrast, I have no sympathy for the "graceful recovery" argument,
because "graceful" is in the eyes of the beholder, and if (or when) a
particular form of gracefulness becomes popular, usage will converge to a de
facto standard rather than what RTFM might say. I am not at all sanguine
that such a de facto standard will be what seems "obvious" to people who
think nesting is "obvious". Moreover, whatever form of error recovery does
get implemented in a parser, I have yet to see an argument that explicitly
named endtags actually make parsing algorithms easier. 

>2) If we allow (or require) named end-tags, we must also allow end-tags to be
>omitted when the named end-tag of a containing element occurs (at least as the
>required form of error recovery).

Not necessarily, or rather, this is *not* an argument for OMITTAG. It's
actually a new kind of minimization (isn't SHORTTAG up for review
anyway?:-)), i.e. a named endtag is shorthand for all, er, contextually
required endtags and "expands" to the necessary number of anonymous endtags.
With this rule, error recovery doesn't apply at all!


Arjun
Received on Sunday, 20 October 1996 19:01:55 UTC

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