I had a quick look at org.apache.xalan.xsltc.runtime.TransformerFactoryImpl
and org.apache.xalan.xsltc.runtime.AbstractTranslet.

Those classes use the .net and .io packages quite a bit (e.g., URL and File
class). These aren't implemented in the CLDC/KVM environment. There are
other JVMs for the Palm, such as Kada System's Mobile VM
(www.kadasystems.com) that support these classses -- and many, many more.
Kada VM also works on Pocket PC devices. However, would think you'd want to
stick with supporting the J2ME framework rather than PersonalJava (which is
what Kada implements, I think).

Anyway, I'll keep looking into it and post again.
-Eric Jung
[EMAIL PROTECTED]


-----Original Message-----
From: G. Todd Miller - XML Tech Ctr - Development
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 05, 2001 6:20 AM
To: [EMAIL PROTECTED]
Subject: RE: RE: XSLTC - why abandon the small guys?


Hi Eric, Shane,

I am currently working on the setErrorListener()/getErrorListener()
part of the TrAX-Translet integration, in the XSLTC code I need to
implement:

        org.apache.xalan.xsltc.runtime.AbstractTranslet:
                ErrorListener getErrorListener();
                void setErrorListener(ErrorListener list)
        and in org.apache.xalan.xsltc.runtime.TransformerFactoryImpl:
                ErrorListener getErrorListener();
                void setErrorListener(ErrorListener list)

I have not had time to look into CLDC and CDC support. Eric, sounds like
you have a lot of knowledge with this- feel free to help out as much as you
want/can. As far as the TraX stuff, I have a checklist of things that need
to be done- if anyone is interested let me know I will send out the list
(it would be a pdf doc). Thanks for the interest!!!

-Todd Miller
                
        >>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
        >>list-help: <mailto:[EMAIL PROTECTED]>
        >>list-unsubscribe: <mailto:[EMAIL PROTECTED]>
        >>list-post: <mailto:[EMAIL PROTECTED]>
        >>Delivered-To: mailing list [EMAIL PROTECTED]
        >>From: "Jung, Eric H" <[EMAIL PROTECTED]>
        >>To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
        >>Subject: RE: RE: XSLTC - why abandon the small guys?
        >>MIME-Version: 1.0
        >>X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
        >>
        >>Hi Shane,
        >>>>Also, the TrAX-Translet integration is still very limited and
meant 
for
        >>prototyping right now
        >>My code below doesn't make use of the TrAX-Translet integration 
components
        >>as I knew it was in its initial stages. But you bring up a good
point; 
will
        >>the TrAX packages work on CLDC with a particular profile? I can
look 
into
        >>this if you like, shouldn't take more than a few moments.
        >>
        >>>>Any tips or education you can contribute to xalan-dev will 
definitely help
        >>here for us to get up to speed on these issues
        >>>>(although I imagine Tom/Todd/Morten already have a handle on
this 
stuff).
        >>I'd be glad to help out. I've been doing quite a lot with J2ME. In
my
        >>opinion you need to decide which configuration(s) and profile(s)
you 
will
        >>support. There are currently two configurations: CLDC and CDC.
Both 
define a
        >>set of classes that must be available to the VM at runtime. The
former 
is
        >>for much more constrained (relative to CDC) devices. Therefore,
CLDC 
defines
        >>a smaller set of available classes. On top of a configuration, (a)
        >>profile(s) is/are added. e.g., the MID Profile (mobile information

devices),
        >>the PDA Profile (for PDAs), etc. The profile defines another set
of 
classes
        >>-- usually GUI and device-specific stuff -- that are guaranteed 
available to
        >>the VM. If the classes you need aren't in the spec of the
        >>configuration/profile combination to which you choose to write,
you 
must
        >>write those classes yourself or do without.
        >>
        >>>>Point out any specific files you think should still be
        >>>>there and an xsltc commmitter can add it back in.
        >>If you plan to support "the little guys" in the future, as it
sounds 
like
        >>you do, in my opinion TransletDemo.prc should be put back in the
        >>distribution. Source code would be helpful too, but based on the 
current
        >>XSLTC source I don't see how it would be compilable. Perhaps
that's 
why it's
        >>not there now...? The Sun distributions never included its source
(as 
far as
        >>I know)
        >>
        >>Let my know any other way I might help out or contribute. I would
very 
much
        >>like to see continued XSLTC support on information appliances.
        >>
        >>Sincerely,
        >>Eric H. Jung
        >>[EMAIL PROTECTED]
        >>Wrox Press contributing author
        >>1-303-781-7947
        >>
        >>
        >>
        >>-----Original Message-----
        >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
        >>Sent: Friday, June 01, 2001 9:08 AM
        >>To: [EMAIL PROTECTED]
        >>Subject: Re: RE: XSLTC - why abandon the small guys?
        >>
        >>
        >>Hopefully the Xalan committers from the xsltc team will chime in
with 
more
        >>details soon (Tom A, Todd, Morten).  A few general comments about 
Xalan
        >>futures and the specific integration:
        >>
        >>---- you Jim Molony <[EMAIL PROTECTED]> wrote ----
        >>> 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.
        >>...
        >>>> From Eric:
        >>...
        >>>> 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:
        >>...
        >>Some of this may be because we want to start integrating the xsltc

model
        >>with the xalan model, which meant quickly bringing xsltc stuff
upto 
DOM
        >>level 2, etc.  Also, the TrAX-Translet integration is still very 
limited
        >>and meant for prototyping right now; obviously this will get much 
better
        >>over time.
        >>
        >>One side question: can anyone verify the CLDC-compatibility (or 
whatever
        >>other profile, etc.) of the various external standards we use?
Namely 
TrAX
        >>-> javax.xml.* packages, the org.w3c.dom.* packages, and the 
org.xml.sax.*
        >>packages?  If those standard interfaces can't run on small
devices, 
then
        >>we'll have a harder time adopting to run there.
        >>
        >>>> 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:
        >>...
        >>Any tips or education you can contribute to xalan-dev will
definitely 
help
        >>here for us to get up to speed on these issues (although I imagine
        >>Tom/Todd/Morten already have a handle on this stuff).
        >>
        >>>> 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!
        >>This may well simply be an oopsie on our integration.  The xsltc
folks 
gave
        >>us a big pile of files which we munged a bit as we fit them into
the
        >>existing xalan source tree, and we may well have dropped some
stuff,
        >>particularly if it wasn't a .java file or obvious documentation.  
Point out
        >>any specific files you think should still be there and an xsltc 
commmitter
        >>can add it back in.
        >>
        >>- Shane

=======================================================================
G. Todd Miller                        Sun Microsystems Computer Company
Software Systems Engineer             2 Network Drive, MS UBUR02-201
GE&IS XML Tech Center                 Burlington, MA 01803-0903
                                      781 442-0176
                                      781 442-1437 (fax)
                                      [EMAIL PROTECTED]

Reply via email to