Re: SGML newline processing

• Mail folder: WWW Talk Jan-Mar 1993 Archives
• Next message: Dan Connolly: "Re: new HTML spec, sample implementation "
• Previous message: Dan Connolly: "Re: dealing with new-lines "
• In-reply-to: Michael Leventhal: "SGML newline processing"

Message-id: <9301081950.AA06847@pixel.convex.com>
To: Michael Leventhal <mleventh@us.oracle.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: SGML newline processing 
In-reply-to: Your message of "Fri, 08 Jan 93 10:32:22 PST."
             <9301081832.AA06229@hqsun4.us.oracle.com> 
Date: Fri, 08 Jan 93 13:50:54 CST
From: Dan Connolly <connolly@pixel.convex.com>

>>>From what I can tell, a newline is ignored by the SGML parser
>>if it's right after a start tag or right before an end tag.
>
>I haven't been following the discussion closely enough to know
>if a suggestion for dealing with the problem will be helpful,
>but...
>
>I use the SHORTREF feature to implicitly recognize an EMPTY
><newline> tag wherever I want newlines after a start tag or
>right before an end tag to be preserved.  The parser will
>generate the implicit tags which my processing engine then
>converts back to actual newlines for output display.
>
>Although this seems like a pain I believe the behavior of
>the parser is logically correct and the only way to be consistent.

Your argument is sound, but we're trying to design a format
that is defined completely in terms of SGML, but parsed by
homebrew code.

So the SGML declaration for HTML turns the SHORTTAG feature
off, saving us some parsing hassles.

If you're using a full-featured SGML parser, you can usually
tweak the DTD to make the stuff parse how you like through
shortrefs and the like. But we're using a bare-bones
SGML parser, so we're just trying to get by without
conflicting with the standard.

Dan