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: Fix for xalan-based xsl:include
Date Thu, 20 Jan 2000 18:13:21 GMT

I don't think this is a bug.  From section 5.5 of the XSLT recommendation:
==============
The template rule to be used is determined as follows:

First, all matching template rules that have lower import precedence than
the matching template rule or rules with the highest import precedence are
eliminated from consideration.

Next, all matching template rules that have lower priority than the
matching template rule or rules with the highest priority are eliminated
from consideration.
==============

So, "*" always matches, no matter what the priority, and has higher import
precidence than "tag2" (import precidence is defined as: "An xsl:stylesheet
element in the import tree is defined to have lower import precedence than
another xsl:stylesheet element in the import tree if it would be visited
before that xsl:stylesheet element in a post-order traversal of the import
tree (i.e. a traversal of the import tree in which an xsl:stylesheet
element is visited after its import children).").

i.e. priority never overrides import precidence.

So I think you either need to use xsl:include instead, or move the "*" rule
to an imported stylesheet (if you don't want to alter stylesheet 2, you
could make another stylesheet that is imported before stylesheet 2).  You
could also try mucking around with apply-imports in your "*" rule.

This is one of the ugliest areas of XSLT, and the one that the XSL WG spent
the most time on.  What you have is the best compremise we could come up
with, all things taken into consideration.

-scott




                                                                                         
                                
                    "Eric SCHAEFFER"                                                     
                                
                    <eschaeffer@posterco        To:     <cocoon-dev@xml.apache.org>
                                      
                    nseil.com>                  cc:     (bcc: Scott Boag/CAM/Lotus)   
                                   
                                                Subject:     Re: Fix for xalan-based xsl:include
                         
                    01/20/00 11:00 AM                                                    
                                
                    Please respond to                                                    
                                
                    cocoon-dev                                                           
                                
                                                                                         
                                
                                                                                         
                                




Great, works well but I've got a question : how priorities between template
rules work ?

I try this, and it doesn't work :

- XML :
...
<page>
    <tag1>Hello</tag1>
    <tag2>World</tag2>
</page>
...

- stylesheet 1 :
...
<xsl:import href="stylesheet2">

<xsl:template match="page">
    <xsl:value-of select="tag1[text()]"/>
    <xsl:apply-templates/>
</xsl:template>
<xsl:template match="*" priority="-1">
</xsl:template>
...

- stylesheet 2 :
...
<xsl:template match="tag2">
    <xsl:value-of select="text()"/>
</xsl:template>
...


And the output doesn't contain tag2 !
I'd like, by default, to destroy nodes that have no "correspondant" rule.
But if I do it this way, the imported rules are not processed...

PS: I tried with lower priority (-1, -2, -3 ....), but still doesn't work.

_______________________________________

Eric SCHAEFFER
eschaeffer@posterconseil.com

POSTER CONSEIL
118 rue de Tocqueville
75017 PARIS
FRANCE
Tel. : 33-140541058
Fax : 33-140541059
_______________________________________

----- Original Message -----
From: Scott Boag/CAM/Lotus <Scott_Boag@lotus.com>
To: <cocoon-dev@xml.apache.org>
Sent: Thursday, January 20, 2000 4:22 PM
Subject: Re: Fix for xalan-based xsl:include


>
> >>       if(null != m_docHandler)
> >>       {
> >>         org.apache.xalan.xpath.xml.TreeWalker tw
> >>           = new
> org.apache.xalan.xpath.xml.TreeWalker(stylesheetProcessor);
> >>         tw.traverse(this.document);
> >
> >What is "stylesheetProcessor"?
>
> Oops, sorry, that should be:
>
>          org.apache.xalan.xpath.xml.TreeWalker tw
>            = new org.apache.xalan.xpath.xml.TreeWalker(m_docHandler);
>
> (copy & paste error).
>
> > Uh, sure, why not? I'll put this in the todo list, but a hint code
would
> > be appreciated.
>
> Sure.  Does anyone have any handy LRU object pool code I can steal to
make
> things a bit quicker?
>
> -scott
>
>
>
>
>
>                     Stefano
>                     Mazzocchi            To:
cocoon-dev@xml.apache.org
>                     <stefano@apac        cc:     (bcc: Scott
Boag/CAM/Lotus)
>                     he.org>              Subject:     Re: Fix for
xalan-based xsl:include
>
>                     01/19/00
>                     06:42 PM
>                     Please
>                     respond to
>                     cocoon-dev
>
>
>
>
>
>
> Scott Boag/CAM/Lotus wrote:
> >
> > Stefano, many many apologies for not getting this to you sooner (and
> before
> > your 1.6 release).  I've been stretched pretty thin over the last
couple
> of
> > weeks for one reason or the other.
>
> Do not worry.
>
> > Stefano, I hope at some point you are planning to make a
> > stylesheet/transform object pool?  Depending on the transform, a lot of
> > time can be spent on the processing of the stylesheet.  Both Xalan and
XT
> > allow you to create stylesheet objects that are independent of the
> content
> > being transformed.
>
> Uh, sure, why not? I'll put this in the todo list, but a hint code would
> be appreciated.
>
> > Here is the patch I think you need to make to the XalanTransformer
parser
> > liaison:
> >
> >   class XMLParser extends XMLParserLiaisonDefault
> >   {
> >     Parser parser;
> >     Document document;
> >
> >     public XMLParser(Parser parser)
> >     {
> >       this.parser = parser;
> >     }
> >
> >     public Document createDocument()
> >     {
> >       return this.parser.createEmptyDocument();
> >     }
> >
> >     public void parse(InputSource in) throws IOException, SAXException
> >     {
> >       this.document = this.parser.parse(in);
> >
> >       // The Xalan stylesheet is normally built from SAX events,
> >       // so if a DocumentHandler is specified, we need to produce
> >       // SAX events from the DOM tree.
> >       if(null != m_docHandler)
> >       {
> >         org.apache.xalan.xpath.xml.TreeWalker tw
> >           = new
> org.apache.xalan.xpath.xml.TreeWalker(stylesheetProcessor);
> >         tw.traverse(this.document);
>
> What is "stylesheetProcessor"?
>
> >         // Note that when cocoon transitions to being more SAX based,
> >         // this function will be called recursivly while the parser is
> >         // still in the middle of a parse, and thus the parser will
have
> >         // created on the fly (or perhaps cloned) since the Xerces
parser
> >         // is not (to my knowledge) reentrant.
> >       }
> >     }
> >
> >     public Document getDocument()
> >     {
> >       return this.document;
> >     }
> >
> >     public boolean getShouldExpandEntityRefs()
> >     {
> >       return true;
> >     }
> >
> >     public boolean supportsSAX()
> >     {
> >       return true;
> >     }
> >   }
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
>
>
>
>






Mime
View raw message