Arthur Alexander wrote:
> Here is my take on the JSP used for XML "apart from HTML" debate.
>
> The primary purpose of JSP is to deliver HTML content, period.
> Why do I feel confident in saying that? Because it is a dynamic
> extension of HTTP-Servlets. Servlets come in two varieties, the
> generic servlet (which is what I believe true XML servers should
> be extended from), and the HTTP servlet.
>
IMHO, you are fundamentally confusing two different concepts:
* How data is shipped back and forth (the HTTP protocol)
* The content of the data being transported (often HTML pages,
but this is by no means the only use for servlets!)
These issues do not have much to do with each other -- see below for more.
>
> HTTP is the 'connection-less' (more correctly stateless) based
> communication protocol that is the standard for Web Browsers to
> request HTML content. It is built into the protocol. A client
> expects to make a GET or PUT or POST type request (among others)
> and to receive an HTTP result that is formatted with content in
> the HTML specification standard.
>
I guess the people that use servlets to serve serialized Java objects (most
commonly to return one to an applet), or sound files, or even dynamically
generated images are cheating, huh :-). The servlet can render its output in
any content type it wants, as long as it says so via the setContentType()
header.
Of course, exactly the same thing is true of the static files served by a web
server. For example, the logo image that appears on a company's home page is
normally of content type "image/gif" or "image/jpeg", not "text/html" like an
HTML page.
>
> It is certainly possible to extend httpd servers and provide
> features that are 'non-standard', and that are possibly even
> quite usefull, but they would not be the norm, and very few
> clients would understand their output or how to deal with the
> extensions.
>
> JSP is designed to get it's parameters from HTTP header items,
> and to formulate a response that will be wrapped in HTTP header
> information (such as cookies, server-type, etc.) which will be
> provided to some extent automatically by the HTTP Servlet that
> the JSP compiler is prepared to extend.
>
JSP is defined to get headers from the HTTP request, that is true, but again
this has nothing to do with whether the content is HTML or not. In fact, the
content uploaded on a POST request is generally of content type
"application/x-www-form-urlencoded" if the client is a web browser, but it does
not have to be. As long as the client and server applications both understand
the content type invokved, they are following the HTTP standard.
>
> Is it possible to extend the JSP model to provide other types
> of content and to extend other Servlet models? Of course, but
> nobody I am aware of is making such a proposal at this juncture.
> Would that be an economical new pattern for development projects?
> I will leave that up to others to debate.
As mentioned above, using servlets to generate content types other than HTML is
very common, and not at all an "extension" to the HTTP standard, or the servlet
API standard. No extensions are necessary, because using HTTP to deliver
content types other than HTML is very commonly used already.
The biggest problems of integrating JSP and XML have more to do with the fact
that some JSP tags cannot be parsed by an XML parser -- as was pointed out in a
different response in this thread -- but that's a completely separate issue.
Assuming the syntax issues are ironed out, JSP + XML would make a very nice
combination for dynamic page generation -- either via translation to HTML for
current generation browsers, or by letting a future generation browser that
understands XML directly do the formatting itself.
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
