Hello Andrew,

Andrew Welch wrote:
>
>> Hello Andrew,
>> 
>> Andrew Welch wrote:
>> >> Hello Alexander,
>> >>
>> >> this is probably a FAQ. It's also an XML topic not an XSLT one.
>> >>
>> >> Look to 2.11 "End-Of-Line Handling" in the XML spec.
>> >
>> >No, it's an html issue.  Carriage returns are normalised to a single
>> >space (I think) so to recreate their behaviour you need to use <br />
>> ><div /> <p /> etc.
>> 
>> No, the original issue is clearly an XML one, as he wrote:
>>    "I thought of doing it with entities in the source XML
>>     like <!ENTITY #13 "<br/>">, but that doesn't work."
>
>But why was he trying to replace &_#13; with <br />?   Because in html
>&_#13; doesn't cause a carriage return, a <br /> does.  He could learn
>all of the possible line endings in xml and still not have the answer.

Line endings in HTML have *not* been the question. He already knew
that he has to use <br/>.
So why do you want to teach him the line endings of HTML?

>> >I think your best plan of action is to modify your xml to replace
>&_#13;
>> >with <br /> (Im assuming that as you can insert entities this
>shouldn't
>> >be too much trouble).
>> This was exactly what Alexander was trying, without success. (or do
>> you mean: manually, with a text editor?)
>
>Inserting entity declarations is not the same as replacing &_#13; with
><br /> with some tool... How would the parser distinguish between &_#13;
>the character reference and &_#13; the entity?  

Ok, it was not exactly the same. You didn't mention the tool.

Entities cannot have a name starting with #. The parser doesn't need
to distinguish, he has to report an error.

>> >If however that breaks a DTD or is not possible, you will have to use
>a
>> >recursive named template that gets called from you text() matching
>> >template.  This can then use substring-before() and substring-after()
>to
>> >recursively replace what you need.
>> 
>> &_#13; cannot be matched or replaced with XSLT functions, as it has
>> been deleted by the XML parser.
>
>Yeah it can - it hasn't been deleted by the parser, its just been
>resolved.  You can still check if a string contains it, just like you
>can check if a string contains &_#120; (the letter 'x').

No, it can't.
You didn't read "2.11 End-Of-Line Handling" in the XML spec very well:

| 2.11 End-of-Line Handling
| XML parsed entities are often stored in computer files which, for editing
| convenience, are organized into lines. These lines are typically separated
| by some combination of the characters carriage-return (#xD) and
| line-feed (#xA).
| To simplify the tasks of applications, wherever an external parsed entity
| or the literal entity value of an internal parsed entity contains either the
| literal two-character sequence "#xD#xA" or a standalone literal #xD,
| an XML processor must pass to the application the single character #xA.
| (This behavior can conveniently be produced by normalizing all line
| breaks to #xA on input, before parsing.) 

#xD is the same character as #13. It must be replaced by #xA, which
happens to be #10.
The XML parsers does the replacement during reading the file effectively
*before doing anything else*.

Obviously, my term "deleted" was misleading, this only applies to the
typical DOS line ending #13#10. Sorry.

>As DC always says 'the reference and the character are one and the same
>thing' - you could write your entire xml file in character references
>(if you were mad). 
>
>As long as you cover all your bases with all possible line endings
>(iirc, the parser can choose which kind of line ending to produce, but
>theres still only a few) then a recursive template is the usual
>technique.
>
>Or for performance, if you were using java you could write a sax filter
>that coverted the value on its way into the trasform, then write a
>template to deal with whatever you has converted line endings to.

You can program great recursive templates or fine sax filters to replace
#13 by the line ending of your choice.
But don't be too disappointed if you see none of your line endings in
your result.

>Or, of course, to save all the hassle just wrap the text that contains
>the line endings in html's <pre>...</pre> which will render the text as
>is (if it fits your needs).
>
>cheers
>andrew  

Regards,
Markus
__________________________
Markus Abt
Comet Computer GmbH
http://www.comet.de


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list