Re: Newlines in element content (i.e TABLES)

At 01:02 AM 9/30/96 CDT, Robert Streich wrote:
>At 08:43 PM 9/25/96 -0400, Paul Prescod wrote:
>>But should every SGML application have to implement it over and over again?
>>That means that between and within ANY ELEMENT you would have to explicitly
>>look out for "meaningless" newlines. Instead of implementing the handling in
>>the parser (which code we expect to be used over and over again) you must
>>implement it in the application.
>
>I would bet that many applications already do. The point is that it has to
>be done somewhere. The application is the only one that really knows if
>the whitespace is significant since it is the one that read the stylesheet.
>Personally, if I didn't write the parser, I'd rescan it's output for
>meaningless-as-defined-in-the-stylesheet whitespace anyway.

The point of Charles' True Information spiel is that the application should
never see data that has not been normalized according to SGML/XML's rules.
If a data character (such as a newline under the banish RS/RE proposal)
occurs in element content, it should be an ERROR, and in an SGML parser's
interpretation it will be. So an SGML-based application (i.e. Panorama) will
report an error (if it supports remapping RS/RE).

That's why RS/RE must either remain as it stands or must be banished from
element content and replaced by a convention like this:

<P
>A new paragraph</P>

>>Then you have to define in your DTD-documentation that newlines in that
>>context are going to be interpreted as "meaningless" which means that we are
>>shifting the documentation and education burden to application designers.
>
>Not in your DTD. It's part of the stylesheet.

I didn't mean that you would put it in the DTD, but in the DTD documentation
(i.e. the TEI Guidlines or the HTML Specification). As I said, this just
shifts the burden from the hundred of us here to the thousands out there. I
prefer the two other proposals that make whitespace handling consistent
across XML-applications.

 Paul Prescod

Received on Monday, 30 September 1996 09:56:10 UTC