Return-Path: <eschaeffer@posterconseil.com>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 91992 invoked from network); 20 Jan 2000 16:33:35 -0000
Received: from unknown (HELO aquarium.politel.com) (195.219.34.1)
  by 63.211.145.10 with SMTP; 20 Jan 2000 16:33:35 -0000
Message-ID: <3ca0c1ae9a5efeb2aad5c3d41c15433d388738de@>
From: "Eric SCHAEFFER" <eschaeffer@posterconseil.com>
To: <cocoon-dev@xml.apache.org>
References: <OF59794C9B.E49DDB0E-ON8525686C.00534162@lotus.com>
Subject: Re: Fix for xalan-based xsl:include
Date: Thu, 20 Jan 2000 17:00:42 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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 ---------------------
>
>
>
>
>
>