Shorttags compromise proposal.

What if end tag GIs were required only for elements *with subelements*
and optional for elements *without*. Then the perl hacker's job is not 
quite as difficult as with nested elements without GIs in end tags and 
the user would have a hard time getting "lost" in the levels. The 
"short fields" in database records would also be able to almost always 
use the short form.

To put the Perl programmer's plight in more formal terms, the language
of elements with an optional GI and no subelements is *regular* (can
be described with a regular expression) but the language described by
the proposal is not. grep may or may not be able to deal with this 
language, because grep is line-oriented (by default or always???), but 
character oriented searchers should have no problem. I think that the
regular expression is:

chargrep "</foo>" | "<foo>"[^<*]"</>"

That's a strange syntax, but the equivalent in your favourite syntax 
should be no more complicated.

The downside of this proposal is that if you add a sub-element to an
element you must add a GI to the endtag. Thus the language is a 
little bit less regular. I would accept a slightly less regular 
language for hundreds of saved keystrokes and those that can't could
stick to the end-tag required syntax.

I suspect that the math people are going to be VERY interested
shorttags. I'm not saying we should go as far as shortrefs, but I think
that a single level of unnamed end tags (as described in is not too hard
to search for.

<ASIDE NAME="Idea"> What about regular SGML/XML where you have nested
recursive elements, such as <DIV>? There is exactly the same problem for
users and perl hackers. There should be a way of labelling start and end
tags that will allow the parser to determine that they line up.

<ASIDE>How about an SGML TC?</>

</ASIDE NAME="Idea"> 

 Paul Prescod

Received on Saturday, 17 May 1997 20:37:42 UTC