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
