OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Whitespace rules (v2)

[ Lists Home | Date Index | Thread Index ]
  • From: "Neil Bradley" <neil@bradley.co.uk>
  • To: xml-dev@ic.ac.uk
  • Date: Mon, 11 Aug 1997 05:42:04 +0000

Paul Grosso wote:

> At 22:48 1997 08 10 +0000, Neil Bradley wrote:
> >----------
> >RULE 2. All whitespace preceding the start-tag and following the end-tag 
> >of a 'block enclosing' element is discarded.
> >---
> >Note: a non-validating applications must refer to a style sheet or
> >configuration file to identify 'block enclosing' elements (perhaps by 
> >applying this rule to elements not specified as in-line elements).
> >As a validating application cannot easily determine this rule from the
> >content model (the first mixed content element in the hierarchy is 
> >block enclosing, as well as all outer layers), it may choose the 
same approach. 
> What if a block enclosing element is contained within a block enclosing
> element?  You appear to be trying to use different terms to describe
> what is effectively the issue of element content versus mixed content.
> How is requiring a style sheet or configuration file to indicate which
> elements are "block enclosing" different from having a DTD or partial
> set of declarations to indicate which elements have element content?

The point about style-sheets etc is that even a non-validating 
formatting application will require one, and it can get its 
information from that source. A validating formatter can do the same 
thing, and it is arguably easier than referring to the DTD, which does not 
directly identify block enclosing elements. A Paragraph element with mixed 
content is a block enclosing element, but an embedded Emphasis 
element, also with mixed content, is not! Of course, block enclosing 
elements CAN be identified from the DTD, it is *just* a matter of finding 
the outer-most element with mixed content, and I am not ruling out 
this approach, just saying a validating processor "may choose the 
same approach" as a non-validating processor for convenience.

I know this is far from ideal, and I hope someone can suggest 
something better. If not, I would still prefer this rule to nothing, 
or to ignoring all line-end codes.


Neil Bradley - Author of The Concise SGML Companion.

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS