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

Caveat Tag Salad (Was: some ERB decisions)

From: Arjun Ray <aray@nmds.com>
Date: Sun, 20 Oct 1996 02:57:23 -0400
Message-Id: <1.5.4.32.19961020065723.0038daac@www.nmds.com>
To: W3C SGML Working Group <w3c-sgml-wg@w3.org>
At 11:01 AM 10/17/96 CDT, Michael Sperberg-McQueen wrote:
>
>The SGML ERB met Wed. Oct 16th and voted on 
[...]
>    B.11 Should XML forbid, allow, or require empty end-tags (7.5)?
>
>Forbid.

The DPH and "graceful recovery" arguments seem to have carried the day. 

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.

Requiring GIs in end-tags is not enough. Leaving "graceful recovery" to
parser implementations is not enough. Not only should an unexpected endtag
be a "reportable error" (assuming we have an adequate definition of this),
but some normative statement (even if it's a non-binding "should") regarding
the forms of error recovery would be the better part of wisdom. 

For instance: the error is not "unexpected endtag" but "endtag missing"
(implying "forced" closure of open subelements.)

Otherwise, given some fragment

   <foo> blah <bar> yada </foo> mumble </bar>

it becomes easy for a parser implementor to give the user "what he wants":
overlapping elements. The lesson, historically proven: Tag Salad is **EASY**.

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
--
"Features whose purpose is to cause errors should be removed" -- Erik Naggum
  
Received on Sunday, 20 October 1996 02:55:24 UTC

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