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