This is all true, but I don't see how it explains why JSP should be used
over say Servlets.
My point is that JSP, being just a Servlet with syntactic sugar, doesn't
provide you with any advantages over using a servlet directly when the
output is XML.
This is because any programmer can write good XML - in a way they can't with
HTML - and therefore there doesn't need to be a seperation of duties between
sitebuilders and programmers. The presentation people get in on the act for
the stylesheets.
Tom
Tom Clarke 665 Broadway
Senior Technical Consultant New York, NY 10012
AGENCY.COM V 212.358.8220 x2798
F 212.982.3105
B [EMAIL PROTECTED]
-----Original Message-----
From: Arthur Alexander <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Sunday, March 21, 1999 8:38 PM
Subject: Re: JSP vs XML
>That would be true if all XML was designed for
>expressing data related to pages of content, that
>could be parsed by a style sheet and given layout
>characteristics. In fact, this was the origin of
>the focus of the XML/XSL design, as well as that
>of SGML/HTML. But they have taken on larger roles
>due to the ability of the format to encapsulate
>structure and meta-data along with content.
>
>Today XML is quickly replacing the older EDI
>(electronic document interface) specifications by
>the ISO (X21 and others, I believe). It is going
>beyond that and providing a packaging mechanic for
>any structured data, including embedded data, and
>what are called 'data islands'.
>
>This provides structure similar to that envisioned
>in the model of MS COM OLE (Object Linking and
>Embedding) where the idea is that you wrap all
>related elements of content into a general container
>that is meant to be one expression of how content
>from many locations and formats relate to one
>another. The individual content islands have meaning
>that is quite separate from the container, and have
>renderings that are not native to that container.
>
>Having a general model and mechanic for expressing
>that model (in java particularly) will become quite
>handy to anyone working in such an environment,
>whether that be commerce oriented or otherwise.
>
>I would further speculate that if XML goes on to
>gather onto itself the concept of behaviours, as
>has the HTML spec., than we could be looking at
>the birth of a new object model, one that is
>expressed in text streams and an open standard.
>
>Java would then be performing the work of a
>'bridge' between object environments, one that
>runs (hopefully) considerably faster than a parser
>would, but is not really an "OPEN" standard in
>the true sense of the word.
>
>Many organizations are at work right now defining
>this object based infrastructure, some only in the
>sense of commerce communications data standards, and
>others in the more object oriented sense, of having
>an XML data island conform to an object data stream
>model, and having an object backed standard to
>reconstitute the stream and give it the necessary
>behavioural characteristics.
>
>An as yet unofficial effort that is being hinted at
>in the press is related to Microsoft moving their
>Active Data Object model (ADO) into an XML based
>standard. We some hint of this in ADO 2.1 and the
>new IE5 DOM. I still believe that Java has the
>upper hand in the ability to create more open
>standards and have them accepted and touted in
>the press and industry quicker, but the merging of
>Java, and other technologies such as COM, with XML
>should not be quickly discounted.
>
>-----Original Message-----
>From: A mailing list about Java Server Pages specification
>and reference
>[mailto:[EMAIL PROTECTED]]On Behalf Of Tom Clarke
>Sent: Sunday, March 21, 1999 2:23 PM
>To: [EMAIL PROTECTED]
>Subject: Re: JSP vs XML
>
>
>It occurs to me that a JSP/XML combination is unneccessary.
>
>The main reason for JSPs existance is to allow an 'HTML
>presentation expert'
>to embed snippets of code. With XML, presentation has
>already been separated
>out - the presentation expert would build stylesheets - and
>embedding the
>XML in directly a Servlet or CGI would have few
>disadvantages.
>
>
>Tom
>
>
>
>Tom Clarke 665 Broadway
>Senior Technical Consultant New York, NY 10012
>AGENCY.COM V 212.358.8220 x2798
> F 212.982.3105
> B [EMAIL PROTECTED]
>
>============================================================
>===============
>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".
>
===========================================================================
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".
