Pid wrote: > Stefan wrote: > >> Christopher Schultz schrieb: >>
> 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 > > > > -chris I'm sorry I missed most of this debate yesterday :-( Admittedly this can be a prickly issue from the jsp compiler stand point in trying to know when an & is just a & and when it's an entity for output to a (x)html or xml response. I have two thoughts that are probably better served on the tomcat-dev list or as comments to the spec committee: 1. Xml spec allows for material to be escaped in the source with <![CDATA[ ..... ]]>. I've done this with jspx files that have included jsp:scriptlet sections. It's easier than trying to make sure all the special characters in the java scriptlet source are properly referenced. 2. It would be nice if the compiled resulting servlet paid attention to the type of the response and handled entity references properly on output. Text/binary/misc types get a dereferenced entity while (x)html and xml output leaves the entity intact as stated in the source jspx. I appreciate the problem as the output doesn't necessarily have to be just (x)html or xml. Sometimes the output is straight text or a binary format of some sort. Maybe the end solution is an attribute of the jsp tag that defines the response type. That would maintain backwards compatibility with existing jspx sources. --David --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
