RS/RE Delenda Est compromise?

At 12:01 PM 12/11/96 -0800, Tim Bray wrote:
>1. Go to the RE Delenda Est model.  This has the advantage that it's
>   trivially easy to explain, document, and implement.  It has some of the 
>   disadvantages listed above; there is some very strong sentiment on the 
>   ERB against this - look from a follow-up from other ERB-folk.

Here is why I am against it: as long as we are going to invalidate most
existing SGML documents, I would really like to introduce a syntax that will
allow people to put back in their pretty-printing-whitespace. I'll elucidate
in a moment.

>2. Expand the -XML-SPACE attribute from two values to three.  The third would
>   be named REMOVE or DISCARD or something, and would be designed to signal
>   element content, i.e. all this white space can be safely ignored.

Ugh. Can't we find a way to use a nice syntax for this instead?

<TABLE{ <!-- insignificant whitespace -->
    <TR{ <!-- insignificant whitespace -->
    <P>Significant      whitespace     <img/>       </P>

    }/TR>

    }/TABLE>

Conceptually this is just a small change from the RE Delenda Est model. It
introduces a mechanism for explicitly allowing insignificant whitespace. But
it does not use a cumbersome, non-intuitive attribute syntax. The new syntax
would have to be introduced through an SGML TC or more SGML declaration
wizardry (is there any more magic left in that hat?). Those that want the
"strict" RE Delenda Est behaviour can just use the old SGML STAGC syntax and
leave out the insignificant whitespace.

>3. Add language to the spec allowing the application to force the 
>   processor to pass through all the bytes regardless of the -XML-SPACE
>   setting.

This can be handled as comments are handled.

 Paul Prescod

Received on Wednesday, 11 December 1996 17:28:07 UTC