Pid schrieb:
Stefan wrote:
Christopher Schultz schrieb:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stefan,
Stefan wrote:
Christopher Schultz schrieb:
Compare this to XSLT. If you want a stylesheet to emit an '&',
don't you
use &? And if you want to emit '&' you have to double it. I
don't see the difference, and I think that the OP is being
unreasonable ;)
Not in my xslt ;-) It depends of the output method. If you output
xml,
& still gets & It is meanless to create a not well formed
xml. I
don't remember what the output method text or html makes.
Fair enough. When you put "&" into your XSLT, the processor sees it
as "entity:amp". When you write that out, the exact display depends on
the output format. If it's emitting XML (or XHTML), you get "&"
right back out.
But, if you're outputting HTML (?) or text (definitely), then you get
'&'. If you want to emit "&" in text mode, you'll definitely
have to
double-up the amps.
The problem is that JSPX is not XSLT. It's really JSP with some extra
junk thrown in. Fortunately for me, I don't have to use it ;)
Yes, I start to understand the ins and outs. Perhaps the spec writers
just could not imagine, that someone will use jspx to do what it is
great for, to produce xml ;-) So I'll go for my filter and wait for
future jsp specs which will include something like
<jsp:output preserve-xml-entities="true" /> or
<jsp:output-method="xml" /> Similar directives for omitting XML
declarations etc. are already included.
i'll weigh in late with this thread...
how then do i differentiate an ampersand that i need to process in the
source document?
in general there are 2 use cases for ampersands in xml generating xml
docs:
1. xml source doc needs to process/contain an ampersand
2. xml generated doc needs to process/contain an ampersand
the solution that the spec implements is double encoding in the source
document - and it makes complete sense if you consider the two cases
above; even if it doesn't make immediate, intuitive sense to an end
user who is moving from the JSP to JSP Document format and who is only
considering the 2nd case.
the JSP document format has some strengths but also some practical
weaknesses which is probably why it's adoption hasn't been as
widespread...
p
Hi again, haven't been on my desk yesterday.
I don't get it. It doesn't seem that complicated. We have a similar
situation with xslt. A xml source document (the jspx document), a
xslt processor (the jsp servlet) and a result (the response). The result
can be xml, html or text (binary data). Depending of the output method,
the xslt processor preserves the "&"s (xml output) or not (text
output). Why not just include a directive <jsp:output-method="xml" />
and handle the amps accordingly?
Perhaps I did not get the point, but for me, it's just missing this
directive.
Regards
--
Stefan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
