You have the wrong person.
----- Original Message -----
From: "Jess Holle and Wendy Vidlak" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, October 22, 2000 5:40 PM
Subject: Re: JSP & XML white paper...
> 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
>
===========================================================================
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
