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

Re: Empty elements (and processing without a DTD)


>Do people really need conditional markup? Or are they really interested in
>conditionally _displayed_ markup. If the latter, style sheets could be used.
>For instance, here's a graceful mechanism for migrating tables into an
>HTML-like XML instance:

This is clearly a superior solution. One additional reason is that in this
way you get the automatic requirement that conditional by synchronous with
the element tree. Another is that if you use marked sections for conditional
display, you have to re-parse to change the display. This is costly in CPU
and/or implementation headaches).

The problem with using elements for conditional display is that you can't
make a single element that does it effectively. One big reason to want to do
this is version control. It would be very nice in SGML to be able to create
a REV element:

<!ELEMENT REV - - ANY>
<!ATTLIST REV
          INSERTED-BY  NUMBER #REQUIRED
          DELETED-BY   NUMBER #IMPLIED>

The idea is that you can keep all your revision history by enclosing any
document portion that change in a REV element that says when it was
inserted, and when deleted (there's a lot of literature on why this is an
effective model for version control, but the same argument holds with most
other models, too).

The problem is that you have to give up most of you validation. To be
effective, REV must be allowed anywhere (so would be an inclusion of the
document element, or appear in a whole lot of content models in a whole lot
of places); and it must allow ANY inside it.

But consider what happens if you replace any element (not just a CDATA
chunk), say, a chapter title. You may go from:

<CHP>
   <CT>Introduction</CT>
   <P>Hi there</P>
</CHP>

to

<CHP>
 <REV INSERTED-BY=1 DELETED-BY=2>
   <CT>Introduction</CT>
 </REV>
 <REV INSERTED-BY=2>
   <CT>Prefatory remarks</CT>
 </REV>
   <P>Hi there</P>
</CHP>

Ooooops: Now the CHP contains no CT, which was probably required. Invalid
document. You can fix that by making CT optional, but you'll end up doing
the same thing everywhere, so all elements are optional in all contexts.
Thus, little validation is left.

Likewise, as soon as you insert one REV inside some element, you can put
anything you want inside the REV, so you can of course slam a CHP inside a
REV inside a FOOTNOTE, or whatever, making a further mess. If OMITTAG is one
it's fairly easy to do this by accident and never see a parsing error.

I have long advocated adding a notion of "transparent" elements for this
kind of specialized purpose: REV would be such an element, as would any
coditional-inclusion one. The parser would require them to remain
synchronous (anything opened inside them must close there, and vice
versa...). However, all validation of content models would be done as if
transparent elements were not on the element stack at all. So, in this case,
the CT would satsify the appropriate token in CHP's content model. Anyways,
enough on that one, it's really for SGML++, not SGML--.

Steve