Thanks for the response Craig,
It seems you misunderstood my comments.
You wrote:
> "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. "
You make my point exactly, and we are in agreement.
All of these content types, and the format of their
transport and rendering - all of this conforms to
the W3C HTML specification! Most common browsers
see this and understand it as HTML content and will
properly render it (or at least try, such as when
a plug-in is required - which they will be happy
to report you do not possess).
They types of extension you are talking about are
not beyond current HTML specs.
What I have not heard anyone really discuss, and
the subject of this conversation thread (which you
did allude to at the end of your note) is HOW will
JSP help me create and manipulate other content
streams and protocols, such as XML?
Could you (or someone else in this forum who feels
strongly about the subject or has a stake in it's
outcome or progress) provide a simple example to
encourage me and others to 'see the light' so to
speak? It might spawn a listener to formulate a
whole new pattern of XML development and
distribution techniques that we can all benefit
from.
-----Original Message-----
From: A mailing list about Java Server Pages specification
and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Craig R.
McClanahan
Sent: Tuesday, March 23, 1999 7:37 PM
To: [EMAIL PROTECTED]
Subject: Re: JSP vs XML
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".
===========================================================================
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".
