cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject Re: XSLTC + Cocoon?
Date Wed, 12 Jul 2000 17:09:42 GMT

Sun made that announcement with little consultation with the xml.apache.org
PMC, or, apperently, other constituents within Sun.  Obviously, there is a
bit of a conflict with Xalan, to put it bluntly.

What we are trying hard to do is to get into a conversation with these
guys.  Sun management has promised that they would be in touch, though I
haven't heard from them yet.  The ideal would be for them to merge there
smarts and code with the Xalan project... they clearly have some good
ideas, and I, for one, would love to work with them.

I don't think there's that much difference with their approach and that of
Xalan2.  The issues are divided into 3 areas:  1) compiler optimization...
generate a class file or class files that linierize templates and possibly
XPath expressions, instead of execution trees, and do compiler-like things
like common sub-expression elimination, and 2) the packaging issue... i.e.
Translets... the ability to ship and stand-alone jar that represents the
stylesheet, all supporting classes, and possibly even the XML parser (if
one is not on the client), so that a full XSLT "engine" does not need to be
available, and 3) the ability to store the XSLT in a processed form to
disk, which could also be done via externalization (rather than
serialization, which is too slow and fragile).  #2 is mainly a client
issue, in my opinion.  We are working on #1 in Xalan2 (also on #1 at this
point), but would love to have contributions in this area, from Sun and
elsewhere.  There are problems to be solved having to do with class
loading.

So my points are a) we are working on similar technology in Xalan, and b)
within the Apache arena, I personally think it would be better if we all
collaborated on a single XSLT processor, that encompassed the Translets
thought.

-scott




                                                                                         
                            
                    Bill Parkinson                                                       
                            
                    <bill_parkinson@        To:     cocoon-dev@xml.apache.org         
                               
                    yahoo.com>              cc:     (bcc: Scott Boag/CAM/Lotus)       
                               
                                            Subject:     XSLTC + Cocoon?                 
                            
                    07/11/2000 10:31                                                     
                            
                    PM                                                                   
                            
                    Please respond                                                       
                            
                    to cocoon-dev                                                        
                            
                                                                                         
                            
                                                                                         
                            



Greetings All,

I read with interest the article from Sun about donating XSLTC
to the ASF. (XSLT Compiler)

My basic understanding of this tool is the following:

somefile.xsl ==>  somefile.java ==> somefile.class (+ libs)

This notion of an XSLTC greatly intrigues me.

Has anyone else been fantasizing about integrating this into
Cocoon 1.7.X?

Envision this beauty of a PI:

<?xml-stylesheet href="index.xsl" type="text/xsl"?>
<?cocoon-process type="xsltc"?>

Seeing this,  Cocoon will have the "xstlc" processor invoked.
Like the xsp processor it checks if index.xsl is up to date or
not.  If not it runs the xslt compiler against it to make a new
class file in the repository.

The DOM tree is passed to this new compiled xslt class instead
of the normal interpretive XSLT processing.

The net result == speed???

xsl's are cached very efficiently here as java byte code!

Has anyone else thought about this?

Likely, someone has a better idea around this subject, I'd be
eager to hear.

How could one get the XSLTC code to tool around with this idea?


Thanks,
Bill Parkinson
-- "Try, try NOT!  There is no try, only do."  -- Yoda

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail ? Free email you can access from anywhere!
http://mail.yahoo.com/





Mime
View raw message