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]
RE: RE: XSLTC - why abandon the small guys?
G. Todd Miller - XML Tech Ctr - Development Tue, 05 Jun 2001 04:59:56 -0700
- XSLTC - why abandon the small ... Jim Molony
- Re: XSLTC - why abandon t... Scott_Boag
- Re: XSLTC - why abandon t... Joseph_Kesselman
- RE: XSLTC - why abandon t... Jim Molony
- Re: RE: XSLTC - why aband... Shane_Curcuru
- RE: RE: XSLTC - why aband... Jung, Eric H
- RE: RE: XSLTC - why aband... G. Todd Miller - XML Tech Ctr - Development
- RE: RE: XSLTC - why a... Gunnlaugur Thor Briem
- RE: RE: XSLTC - why aband... Joseph_Kesselman
- RE: RE: XSLTC - why a... Gunnlaugur Thor Briem
- RE: RE: XSLTC - why aband... Shane_Curcuru
- RE: RE: XSLTC - why aband... Jung, Eric H
