From: Ship, Howard (hship@primix.com)
Date: Mon Sep 18 2000 - 15:04:21 PDT
I'd like to check folks opinions about a subject close to home: this whole
XML/XSL tranformation thing.
The conventional wisdom is that you do all your work internally, then always
convert to XML and then convert that to appropriate HTML, XHTML, WML, etc.
for your client.
At the core of this is the idea that users will visit the same site using
their Web TV, thier Palm, thier Linux-powered wrist watch or the tactile
response browser embedded in their bridge work. And that for any of these,
there as specialized markup language (or a specialization of an existing
markup language) that can be transformed to from the XML.
I mean, it sounds plausible, but I have big questions on practicality and
scalability.
I've done a lot of work web applications (targetting desktop browsers) and a
bit of thought on alternate targets, such as Palms or other low-powered
browsers.
My current opinions are:
1) Desktop vs. Palm vs. Phone (vs. watch vs. bridge work) ... each of these
is a fundamentally different application. It's more than simplifying and
re-arrainging things on the "page", the style of navigation and interaction
will have only distant simularities between the different devices (or should
I say "experiences"?).
2) XSL transformation. O(n)? O(n ^ 2)? O(n!)? This stuff might work fine
on the bench, but a bad rule that leads to O(n ^ 2) or better is going to
bring your application server to its knees. I haven't done much with XSL,
but it looks like a declarative scripting language; a rules engine for
transforming the DOM tree. Still, any language needs a debugger .. have one
handy for XSL? Didn't think so. There's also some issues with
transformation and memory usage ... is keeping a gigantic tree of temporary
objects (with a life span of a single request cycle) practical?
3) Memory usage. Call me Puritan, but I don't like to build something just
to thow out 60% (80%? 99.732%?) of it. Most of the XSL is probably for
editting things out ... removing text, images, etc. (and that probably is
O(n)) ... but The People demand performance so not generating that XML in
the first place is hard to resist.
4) Got a use case? Where's the use case that demonstrates the need for all
this (also, see next note). Somewhere, there's a heavily caffinated hacker
showing off to his friends that he can see the same vapid application on
Netscape and his browser-enabled coke-bottle eyeglasses.
5) Re-use. Is this the best approach for re-use? Isn't the whole argument
based on the idea of doing *way* too much in the presentation layer? J2EE
and/or Jini provides all the mechanisms for good back ends, where the data
comes from real objects and the presentation layer is a thin, but critical
presentation layer.
6) Finesse. Users demand a certain level of finesse for thier applications
... on the desktop, they all but demand involved interfaces super-charged
with DHTML and JavaScript. Sometimes, for finesse, you have to break the
rules ... think out of the box ... do something wierd that isn't going to
fit into a normal XSL rule. How complicated are those XSL rules going to
become ... and how far will the stretch before breaking.
*********************
The way I would tend to go is to use a component-based object model for the
presentation layer, and get my re-use from the back end objects (EJBs) and
component re-use in the presentation layer. Then set out to do the
application for each principal kind of device: desktop, palm, phone,
bridge-work, etc. Re-use the back end objects, use subclassing and
aggregation to create variations of the controllers and components in the
presentation layer but be prepared for the three (or more) applications to
fork in three (or more) different directions, reflecting the different media
they belong to. Don't hamstring yourself with a cookie-cutter approach.
Employ re-use where it can (maybe) be managed ... inside a Java IDE, not in
Notepad editting a giant XSL script.
I would recommend Tapestry (http://sourceforge.net/tapestry) as the
presentation layer, but I'm biased, being the author.
-----Original Message-----
From: S. Mike Dierken [mailto:mike@knownow.com]
Sent: Monday, September 18, 2000 5:35 PM
To: Gavin Thomas Nicol; fork@xent.com
Subject: RE: [Wash Post] The WAP backlash continues...
Have you looked at Apache Cocoon?
http://xml.apache.org/cocoon/index.html
It does something similar.
> -----Original Message-----
> From: Gavin Thomas Nicol [mailto:gtn@ebt.com]
> Sent: Monday, September 18, 2000 1:42 PM
> To: fork@xent.com
> Subject: RE: [Wash Post] The WAP backlash continues...
>
>
> > It lets you do lots of things with simple tools. It makes you
> > consider most systems for generating dynamic web content
> > (Apache mods, PHP, ASP, servlets, etc.) as transformation systems.
>
> Yep. I codified this in an internal "transformation architecture"
> that also regarded the functions as being compositional (something
> roughly akin to combinators). Lot's of fun ideas to be had in that...
This archive was generated by hypermail 2b29 : Mon Sep 18 2000 - 15:08:53 PDT