Re: (dsssl) Loss of separator

["G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>]

At 2003-02-13 11:54 +0100, Jany Quintard wrote:
> I have a stupid question (stupid because I am sure that the answer is
> under my very nose and I don't see it)

Not stupid because SGML record-end rules are understood by very few people 
in this world, and I don't consider myself one of them!

> <p Level="01">
> Some text
> <l linkend="NameOfLink">Text of link</l>
> text following the link
> </p>
>
> Output:
> <P
> >Some text
> <L
> linkend="NameOfLink"
> >Text of link</L
> >text following the link</P
> >
>
> What puzzles me is that the breakline between the link element and the
> text following it is lost. I would have bet that it was the same as a
> space.

You would lose that bet.

I gather the record-end rules existed to accommodate the human author of 
the markup.  Remember that visual screen editors of SGML markup were an 
invention of the marketplace, and not conceived of (I'm told) by the 
orginators of markup technologies.

Imagine you are in the middle of a paragraph (your "Some text text 
following" and you decide you want to inject a link in the middle.  Ending 
your injected markup with a newline is considered part of the act of 
injecting the markup and not part of the text in which the markup is being 
placed.  So the record-end rules would magically eat those newlines in the 
interpretation of the embedded markup.  But for some reason it doesn't 
really eat that one ... it somehow remembers that one was there and then 
depending on what follows the newline that follows may or not be eaten.

Or something like that ....

It was a real test of whether you understood what was going on in an SGML 
processor or not .... and I failed the record-end processing section of 
that exam.

I hope this helps.

....................... Ken

--
Upcoming hands-on in-depth   Europe:         February 17-21, 2003
XSLT/XPath and/or XSL-FO     North America:      June 16-20, 2003

G. Ken Holman                mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.         http://www.CraneSoftwrights.com/z/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6                      Definitive XSLT and XPath
ISBN 0-13-140374-5                              Definitive XSL-FO
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1              Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/z/bc


DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist