[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-ohs-talk] Using Java in XSLT


Jack Park wrote:
> " As evidenced by the inclusion of JAXP in J2EE 1.3, XSLT and XML will
> continue to prove integral to many J2EE applications. Because J2EE
> developers will be occasionally asked to create stylesheets, they should
> understand the possibilities provided by XSLT Java extensions. Xalan's Java
> extension capability provides Java developers with a mechanism to process
> input from a stylesheet and return DOM fragments or String s to the XSLT
> processor. This capability allows developers to break XSLT limitations and
> take full advantage of Java's flexibility. Developers can tackle many more
> transformation challenges without becoming XSLT gurus. In other words, with
> the help of Java extensions, we can perform complex XML transformations and
> continue to lead normal lives. "    (01)

Let's hope that the use of XML evolves beyond SAX and DOM though.  Both
are terrible document representations.  A hybrid that allows both push
and pull as well as XSD-typed objects and the option of not having to
graph an entire document is the way to go in the future.  Powerful
enough for developers who know how to write a state based parser, but at
the same time, easy enough for the people who were too afraid to touch
SAX.    (02)

I think that the use of XSLT will diminish quite a bit when XQuery
implementations become more common.  The document people will stick with
XSLT, but the data people will gravitate toward XQuery.  Too bad the W3C
couldn't have figured out a nice middle ground and produced a single
specification, eh?    (03)

-- 
Tom Bradford - http://www.tbradford.org
Chief Architect - The dbXML Group, L.L.C.
Developer - Apache Xindice (formerly dbXML)
Maintainer - jEdit-Syntax Java Editing Bean
Co-Author - O'Reilly's "Learning Xindice"    (04)