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