- From: Eve Maler <eve@doctools.com>
- Date: Thu, 12 Dec 1996 06:56:17 -0500
- To: gtn@ebt.com (Gavin Nicol)
- cc: w3c-sgml-wg@w3.org
>>Somehow, the element-vs.-mixed distinction needs to be made >>in cases where it's critical for rendering or other processing. Where is >>the right place to make the distinction, if there's no DTD? Is is the >>stylesheet? If so, are there any technical barriers to doing this? > >I'd like to hear from people the cases that they can think of >where the distinction is truly necessary. > >In cases where it really *is* necessary, I see no problem at all in >having/requiring a "validation" layer that *requires* a DTD so that >element and mixed content can be distinguished. This layer would >validate the post-parse representation using whatever rules need be >applied (one might be to use SGML's "normal" rules). > >I cannot see why a *parser* for an essentially trivial syntax need be >bothered by this. > >Conceptual model: > > input-->parser-->events/grove------------------+-->application > \ / > +-->filter-->events/grove+ > >where "filter" can perform some rules-driven (ie. DTD, DSSSL >spec. etc.) transformation of the parser output. The most obvious case is plain old rendering. If you've just invented a DTD on the fly that contains a list that itself can contain some list items, and the input looks something like this: <list> <item>Blah</item> <-- <item>Blah</item> <-- <item>Blah</item> ... </list> ...do you render those extra lines, or what? In this case, validation isn't even on the author's or renderer's mind, and yet you need to know the distinction. Eve
Received on Thursday, 12 December 1996 06:56:08 UTC