for server-side XML-XSL -> HTML processing, check out
Cocoon at http://java.apache.org
It comes configured with LotusXSL and Kaola XSL processors plus
IBM's XML4Java and Sun's XML parsers. The parsers and the
processors are configurable. kool !
It is a servlet that can be plugged into ur web server
environment. Have tested it, and found it fun-tastic !.
this kind of server-side processing is gonna take off. big-time.
- raghu
>So are there any examples where it is advantagous to generate XML from JSP?
>
>I'm more than aware that there is a lot of HTML to be generated for the
next
>few years and that JSP will be a good direct way of doing it. However, when
>I can use XML - because my intranet is entirely IE6, or it is for machine
>reading - does JSP provide me with any significant advantages?
>
>A further thought - one of the things that will make life easier for us is
>the development of server side XML/XSL -> HTML processors. That way our
>servlets and CGIs can generate XML and have them post-processed into HTML
>for old browsers and sent as XML for new browsers.
>
>My feeling is that ASP and JSP will last only as long as it is necessary to
>generate HTML directly - which may be a long time :( - once it is more
>structured kinds of data we are generating, they become unnecessary.
>
>
>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: Jack Humphrey <[EMAIL PROTECTED]>
>To: Tom Clarke <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
><[EMAIL PROTECTED]>
>Date: Tuesday, March 23, 1999 1:42 PM
>Subject: RE: JSP vs XML
>
>
>>Tom,
>>
>>You make a good point, but using XML/XSL for presentation is probably
>>going to take a while to catch on. If you can get away with requiring the
>>latest web browser that supports XML/XSL (how well does IE 5 do that?),
>>then the only remaining benefit of JSP is dynamic compilation, which is
>>nice when developing.
>>
>>I'm a big believer in separating content from presentation, so I can't
>>wait for the day when all the apps I write generate XML/XSL. In the
>>meantime, however, I have to be realistic and accept the blurred lines of
>>technologies like JSP.
>>
>>Jack Humphrey
>>Software Developer, Trilogy Software, Inc.
>>
>>> -----Original Message-----
>>> From: A mailing list about Java Server Pages specification and reference
>>> [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Clarke
>>> Sent: Monday, March 22, 1999 9:31 AM
>>> To: [EMAIL PROTECTED]
>>> Subject: Re: JSP vs XML
>>>
>>>
>>> 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".
>>>
>>
>>
>
>===========================================================================
>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".
