[Prev][Next][Index][Thread]

Re: RS/RE: basic questions



At 1:40 AM 10/3/96, Rick Jelliffe wrote:
>There is also the Interleaf option, of saying that all RE or RS are
>ignored (by the application if not the parser): that all of them are just
>there for nice formatting of the source code (assunming content models
>like ( #PCDATA | an.element) are out of XML and RE/RS aren't used for
>content model navigation).

I don't think this works, because the SGML behaviour also allows space and
tab (SEPCHAR) characters that are ignored in element context. So just
bundling RS/RE doesn't enable all the formatting that we used to have in
SGML source. Since this is the sole justification for the rules in the
first place, we aren't really gaining that much. by preserving RE/RS but
loosing the spaces. To return to Paul Prescod's table examples, we also
want whitespace for when tables nest:
<table>
   <tr>
     <td>
        <table><tr><td>cell1</td><td>cell2</td></tr>
               <tr><td>cell3</td><td>cell4</td></tr>
        </table>
     </td>
     <td>Not a nested cell</td>
   </tr>
    ....
</table>

But all the RS/RE folding proposals fail to allow that because of the
element content rules. (unless we want to make some strange rules about
inter-tag strings of whitespace).

My argument against quoting is that SGML compatibility should not be _more_
important than user utility (and familiarity is a significant component of
utility for most busy people who aren't toolsmiths).

 So we really need to bite the bullet, lump all whitespace together, make
it all significant, and be done with it.

>At the other extreme, there could also be something like the old Macintosh
>convention, so that RS/RE is shortreffed to <p> or the paragraph tag (or
>"<>" even).  In otherwords, force RE/RS to have a definite meaning largely
>precluding its use willy-nilly inside mixed content elements. (It means
>that XML might have trouble in editors that handle wraparound by inserting
>linebreaks, but that would be bearable.)

  This will break my ability to choose my own DTD (or force some form of
minimization_, and still disallows whitespace in element content -- never
mind that we can't tell if we're in element or mixed content when parsing
without a DTD.

   -- David

RE delenda est.

--------------------------------------------+--------------------------
David Durand                  dgd@cs.bu.edu | david@dynamicDiagrams.com
Boston University Computer Science          | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/    | http://dynamicDiagrams.com/