Hi Jess. Thanks for your thoughtful comments. I'll have to be very
brief right now. Hopefully I'll be able to get back to this later in
the week.
The main purpose of the paper is actually not XSLT related; rather it is
that "JSPs can be used to do XML". We have encountered a number of
people who thought that JSPs were only for HTML, and were surprised that
was not the case. That misconception has been slowly going away in the
last few months (for example, my J1 talk talked about that), but we
needed a white paper making that statement, and it took us a while to
get the paper out.
On the XSLT side, we are not trying to say that "XSLT is just for
stylistic nuances". There are a number of places where it makes a lot
of sense to use XSLT. It just depends on the case. It is very hard to
cover the whole space without writing a much larger article, and it is
even harder to put then in a somewhat coherent structure without making
strong assumptions about the background of the readership. Here are a
few items, on the run:
* The paper (& jakarta-taglibs, with which I am very involved) includes
a tag to apply an XSLT stylesheet to a source. A number of people are
using that, including some in the struts community. I expect that
JSR-052 (the standard tag library) will include tags to do exactly that.
* I am a firm beliver that XPath & JSP will have a happy life
together. I suspect that the expressive power of XPath and the
iterative-computational extensiblity of JSP can be mixed well. But we
have not explored that yet, so I didn't want to point into that
direction in the paper yet.
* Filters (in Servlet 2.3, as well as in other technologies, like
Cocoon) is a good way to apply an XSLT transformation to some dynamic
content. I expect people to use such a transformation for content that
is generated from a number of sources, including JSP.
* If the structure of the content is well organized, and the
interaction model is coherent, an XSLT transformation at the end of the
pipeline makes sense. THat is the case for a publishing system.
Whether it applies to you in other contexts, is hard for me to
generalize, but I've had a substantial number of people (a large
percentage, actually, but my sample is not random) that have told me
that they started with an XSLT-based approach and then moved back to a
JSP approach for the reasons mentioned in the white paper.
* The last batch of questions on encoding are actually very good. I
can assure you that they are not at all related to the evaluation of
XSLT vs JSP. But you are right, we have not done as much as we should
have done on I18N/encoding support. That is actually the last batch of
changes on 1.2 that we are working on in the expert group, and some of
your earlier messages are food for those discussions. It would be great
if I can send you mail directly on Monday to check a few things, since I
may need extra context and/or may want to run some ideas by you.
Overall, I do not believe we know with 100% confidence what *THE*
solution is; we are all, as a community, discovering it. But the white
paper is my best understanding of the space right now (within the
limitations of the format). I am pretty sure that both JSP and XSLT
have a role in that solution space. My intention that people will
think of XSLT and JSP as tools in the arsenal, to be used after
considering benefits and costs.
Hope this helps,
- eduard/o
Jess Holle and Wendy Vidlak wrote:
>
> Regarding http://java.sun.com/products/jsp/pdf/JSPXML.pdf:
>
> The gist of this white paper seems to be mainly:
>
> Limit XSLT usage to just stylistic nuances between one format (see Page
> 13).
>
> On the one hand, that's fine for some things. I am not knocking JSP
> (barring a few omissions).
>
> On the other, if your input data is XML and XSLT is sufficient to convert it
> to the desired output format without adding development time cost, then why
> not use XSLT?
>
> Even where XSLT is insufficient for the task, why not use XPath???
>
> If you don't, then you have to take charge of parsing the XML yourself or
> converting it to DOM and then write utilities to pull the results of
> interest out. In the end, you end up writing a portion of XPath in most
> cases. That portion will be quite small if you're doing something as
> ridiculously simple as the paper's example. The example on page 3 does show
> how the end result of this approach is proprietary syntax (i.e. one has to
> read your taglib documentation before understanding anything complex). As
> it is now, however, the example on page 3 is still extremely misleading in
> that for most *real* examples one has to write and maintain a fair amount of
> tedious, *silly* code if you don't use XPath here. The example beginning on
> page 3 *really* should have used XPath via an off-the-shelf library for such
> and shown how to wrap that (very thinly) as a taglib. Also, I'm not certain
> JSR 31 will obviate the need for XPath -- it depends on the JSR 31
> performance, features, etc. [e.g. why create objects for much of the XML if
> you just want to issue a single general query for a list of strings from
> it?]
>
> At the very least, the example beginning on page 3 ducks the whole issue as
> to how to pull data from XML and puts it in a pretty abstraction tag. Nice
> technique -- I've got no argument with it. It's just that it makes it look
> like a full, complete answer to the problem and leaves a good deal of the
> problem unsolved. The XSLT example solves the whole problem, thus the paper
> does a rather unfair comparison between the two techniques.
>
> Also, why denegrate a single pipeline? Because XSLT then infringes on JSP's
> "turf"? Out of fear that JSP might be replaced with XSLT and Java
> callbacks? [Which would be silly in that XSLT doesn't have all the broader
> HTTP session/servlet/etc characteristics of JSP and thus is destined to
> serve as a slave piece in any architecture to JSP.]
>
> There are several unanswered pipelining questions which you left dangling in
> the wind, e.g.:
> * How about examining what it would take to make XSLT
> tags be a (standard) JSP taglib? Perhaps it requires
> extensions to the taglib API. Perhaps it is simply
> impossible. I don't know (haven't had time to
> investigate myself). I just know this is the sort of
> integration I've been expecting reading the nice little
> note in early (and later) JSP specs stating that a
> future release would wonderfully integrate JSP and
> XML technologies.
> * How can one portably *dynamically* set the JspWriter's
> encoding (i.e. before the writer has been used but after
> the page logic has been entere)? If one cannot do this
> now, then why not? When will we be able to?
> * For that matter when will we just be able to use an
> OutputStream when appropriate? [For instance, why can't
> I do a JSP-generated GIF if I am careful not to leak
> linefeeds, etc, to the GIF?]
> * At a *bare* minimum, how can I portably guarantee a page's
> character encoding (i.e. as UTF-8) without statically
> committing to a response content MIME type (i.e. I need
> to be able to determine it dynamically). The
> internationalization discussion is purely "suggestion"
> in an appendix. I need to be able to rely on this! Even
> the suggestion implies that I have to statically commit
> to both MIME type and character encoding.
> * As I understand it, JSP cannot be made to XML-escape
> characters that are outside the scope of the current
> character encoding. Is this true? If so, why is there
> nothing built into JSP along these lines?
> * Probably a repeat of the last question, but why the
> assumption that the page's encoding is the same as the
> output's? XSLT makes no such (erroneous) conclusion.
>
> Are the last several of these questions the real reason to denegrate the
> single pipeline architecture?
>
> I understand Sun is far from XSLT ignorant (given XSLTC, etc). I also
> understand the white paper in question is first and foremost JSP evangelism
> (and thus wishes to seem far from behoven to other technologies for dealing
> with XML). I did expect some of the issues I listed to be plumbed, however.
>
> --
> Jess Holle
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
