Scott, Jospeh,
Thank you for explaining your vision more clearly. Everyone I have asked is
in agreement that Apache XML/Xalan, is the best place for XSLTC, and there
seems to be many good things to be gained by combining the excellent
features of both into one development project.
My lack of detailed knowledge of the project meant that my questions
actually hid the practical issue that was behind them, which is better
expressed by the summary below from the author, Eric Jung, I am working
with. We would like to illustrate the exciting idea of using translets on
the Palm OS, a feature that was to some extent supported (and even
advertised by the bundling of a demo translet application) by the XSLTC
project up to alpha 3. However the main problem seems to be that classes and
interfaces required by XSLTC have since diverged from what is available on
the most up-to-date versions of Palm/J2ME configurations.
Since the deadline for the project is very near, we have concluded that a
demonstration using Xalan/XSLTC code is infeasible. However, it is
encouraging to hear that the vision does very much include the small guys!
This was our instinct, even though there is not much discussion visible
about the vast possibilities here.
Regards,
Jim.
>From Eric:
Jim,
Here's my response concerning the execution of translets on a Palm-OS
device. I have restricted these notes to the execution of translets
and not their compilation, since compilation would typically be done
on a build workstation (not a Palm-OS device) with the rest of the
Palm application:
There are a number of classes and interfaces used to run a translet
that are not part of the J2ME CLDC configuration. These
classes/interfaces may be part of the CDC configuration, but I didn't
look into that because, you'll remember, the Palm
(and PDAs in general) are CLDC-class devices--not CDC. It appears as
though Pocket PC devices will be classified as CDC, but I digress.
One might hope the missing classes and interfaces are provided at the
J2ME profile level, but, at least for the Palm kjava overlay (the
closest thing to a CLDC/PDA profile today), this is not the case. The
official PDA profile is still a JSR (see my chapter for the link), so
we can't rely on the classes/interfaces needed to run translets being
there. Perhaps they are implemeted in the MIDP profile (the profile
used by mobile phones), but I highly doubt it.
Here is the simplest code to execute a translet using XSLTC as it is
released with Xalan-J 2.1.0, **not** XSLTC Alpha 5. This code does
not utilize the TrAX-translet integration by G. Todd Miller:
import org.apache.xalan.xsltc.*;
import org.apache.xalan.xsltc.dom.DOMImpl;
import org.apache.xalan.xsltc.runtime.TextOutput;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
import org.xml.sax.*;
import org.xml.sax.helpers.DefaultHandler;
import java.io.ByteArrayInputStream;
public class ContactTransform extends DefaultHandler {
public ContactTransform(byte[] buf) throws Exception {
//load and create the translet
Class cls = Class.forName("ContactTransform");
Translet xlet = (Translet)cls.newInstance();
//create a SAX parser and get the XMLReader object it uses
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
XMLReader reader = parser.getXMLReader();
DOMImpl dom = new DOMImpl(); //will contain the parsed source XML
//set the DOM's DOM builder as the XMLReader's SAX2 content handler
reader.setContentHandler(dom.getBuilder());
//Parse the document, building a DOM tree
reader.parse(new InputSource(new ByteArrayInputStream(buf)));
TextOutput txtOutput = new TextOutput(this);
//pass the translet the source XML and a handler
xlet.transform(dom, txtOutput);
}
public static void main(String[] args) throws Exception {
ContactTransform ct = new ContactTransform(someByteArray);
}
}
This code is a subset or simpler version of the command-line translet
"runner" that comes with XSLTC,
org.apache.xalan.xsltc.runtime.DefaultRun. It's the DOMImpl object
that causes us problems in the J2ME-CLDC-kjava environment (but no
problems in J2SE and J2EE). The classes/interfaces that are not in
the environment but upon which DOMImpl depends are:
java.io.Externalizable
java.io.ObjectInput
java.io.ObjectOutput
java.io.BufferedReader
java.io.File
java.io.FileInputStream
java.lang.ClassLoader
java.lang.NoClassDefFoundError
java.util.Properties
java.lang.Cloneable
java.lang.CloneNotSupportedException
java.lang.Double
java.lang.Number
java.text.DecimalFormat
java.text.FieldPosition
java.io.BufferedWriter
java.io.FileOutputStream
java.util.Dictionary
It's worth noting that the current Xalan source has another class
called DOM.java.Palm that is uncompilable and still uses the old
com.sun.xslt.dom package. It appears to be part of an older version,
before interface DOM and class DOMImpl were separated, and perhaps
when translets still ran on the Palm-OS. A key indicator of this is
that it uses java.util.Hashtable (available on CLDC) while the new
DOMImpl imports but doesn't use java.util.Dictionary (not available
on the CLDC). Even though it doesn't actually use Dictionary, merely
importing it will be problematic when preverifying translets for the
Palm-OS. It's also worth noting that the TransletDemo.prc
demonstration that came with XSLTC Alpha 5 and before has
mysteriously disappeared from the Apache distribution!
-eric
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 30 May 2001 14:32
> To: [EMAIL PROTECTED]
> Subject: Re: XSLTC - why abandon the small guys?
>
>
>
> > With the move of XSLTC alpha to Xalan, and the change of
> package names,
> > etc., it seems that this momentum has gone...
>
> ?? Why do you say that? I don't think the target for XSLTC
> changes, and
> small devices certainly should remain important. By bringing
> XSLTC into
> Xalan, all we're trying to do is combine the technology where it makes
> sense. The size of a Translet should remain the same. The
> ability to be
> fully conformant with XSLT while at the same time keeping the smaller
> package size seems to be the larger issue, not the packaging.
> I'm very
> disturbed to here you say that you think the goals have changed.
>
> Let me try and rearticulate what I think the vision is:
>
> 1) Shared core parse, abstract syntax tree, and optimization rewrite.
> 2) Shared source tree API.
> 3) Shared multiple choices for source tree implementation:
> compact, fast
> incrementat, DOM wrapper.
> 4) Shared serialization module.
> 5) Intepreted runtime for tooling, editing, etc.
> 6) Compiled runtime for very high performance.
>
> By no means do I see the small guys being abandon. Quite the
> opposite, I
> think. By being able to add a lot of features to the
> interpreted runtime,
> you can keep the compiled runtime leaner, smaller, and faster.
>
> -scott
>
>
>
>
>
>
> Jim Molony
>
> <[EMAIL PROTECTED] To:
> [EMAIL PROTECTED]
> m> cc: (bcc: Scott
> Boag/CAM/Lotus)
> Subject: XSLTC -
> why abandon the small guys?
> 05/29/2001
>
> 03:49 PM
>
> Please
>
> respond to
>
> xalan-dev
>
>
>
>
>
>
>
>
>
> Hi -
> I'd be interested in any views on using XSL on information
> appliances/J2ME/limited configurations. There seemed to be momentum in
> maintaining a Palm compatible version of XSLTC up until alpha
> release 3.
> With the move of XSLTC alpha to Xalan, and the change of
> package names,
> etc., it seems that this momentum has gone... (I presume
> there will only be
> the Xalan XSLTC project now?).
>
> I guess I'm asking whether there's some good reason for _not_
> doing XSLT on
> lightweights that I'm missing. For instance, the ability to
> serve translets
> to small devices that could then cache them would seem to have huge
> potential that could outweigh doing billions of XSL
> transforms on a server,
> however fast that could get.
>
> Or is it the view that limited configuration devices have a limited
> life-span anyway, and that a full SDK configuration for
> anything bigger
> than
> matchbox is not far off?
>
> Be glad of any insights into this.
>
> Thanks,
> Jim Molony.
>
> Jim Molony
> Wrox Press
> Programmer to Programmer(tm)
>
> 44 (0) 121 6874192
> www.wrox.com
>
>
>
>
>
>
