I18n is actually mapping from key to value, so you could easily use i18n for 
what you want. Another option is using a locationmap (see forrest). And yet 
another option, is writing your own very simple transformer which just handles 
some SAX events specially (like translating some attributes into different 
attributes using some HashMap)
 
The only thing I really discourage you to do, is doing this very thing in 
xsl....xsl is not meant for mappings IMHO, and is terribly slow if you (mis)use 
it for this purpose. I think there is a simple rule of thumb you can use wether 
or not to use xsl:
 
When it is simple to achieve your aims with a SAX transformer but hard in xsl 
it is almost always better to use a transformer for it. 
 
 
With hard in xsl I mean hard from a DOM POV (not for reading for humans, but 
for a computer), so something like: if there is an element from root somewhere 
that contains an id attr that is equal to the current node value, then....
 
 


Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-------------------------------------------------------------
[EMAIL PROTECTED] / http://www.hippo.nl <http://www.hippo.nl/> 
-------------------------------------------------------------- 

-----Original Message-----
From: Jan-Willem Boer [mailto:[EMAIL PROTECTED]
Sent: maandag 25 juni 2007 13:50
To: [email protected]
Subject: Re: catalog and xslt document() function


Ard Schrijvers schreef: 

By the way, 



what are you using the catalog for anyway? Does sound like some sort of i18n. 
Trying to simulate i18n stuff in xsl can/will result easily in absurd 
inefficient xsls, taking up to seconds to run,



Regards Ard



  

uhm... the catalog file is used for mapping PUBLIC id's to alternative SYSTEM 
id's ... 
No i18n involved in this case.

Jan Willem



  

Alexander Daniel schreef:

    

I don't know direct answers to your questions but I can recommend a 

different approach:



Instead of using the XSLT document() function you could use the 

Include transformer 

(org.apache.cocoon.transformation.IncludeTransformer) which also 

supports caching. We use it successfully in our project.



Alex



      

We do use the cinclude transformer in the same project. But 

in this case 

i need to check the contents of the document before it can be 

included. 

This would require a few extra steps if we would use the cinclude 

transformer so that option is not preferable over the xpath document 

function.



For example:

<xsl:variable name="doc" select="document(@path)"/>

<xsl:if test="$doc/some-element">

  <xsl:copy-of select="$doc"/>

.....



I think the XSLT processor should be aware of the catalog 

file in this 

case.



Jan Willem



    

On Jun 21, 2007, at 1:21 PM, Jan-Willem Boer wrote:



      

Jan Willem Boer schreef:

        

Hi,



I ran into a problem with the catalog file and the xslt 

          

document() 

    

function.



To include a document into the XML that flows through a Cocoon 

pipeline, I am using the document() function in an XSLT 

          

stylesheet:

    

   <xsl:copy-of select="document(@path)"/>



The document-to-include contains a DOCTYPE declaration 

          

referring to 

    

an external entity:

   <!DOCTYPE something PUBLIC "-//Company//DTD SOMETHING-XML//NL" 

"something.dtd">



I added the DTD-file to the directory WEB-INF/entities 

          

and added a 

    

line to the catalog file containing the PUBLIC and SYSTEM 

          

identifiers.

    

The problem occurs when i use the document function to 

          

include the 

    

document directly with an absolute path, the catalog file is 

ignored, and the DTD is not found.

To circumvent this, I was forced to redirect the 

          

document() function 

    

to a cocoon pipeline like this:

   <xsl:copy-of select="document('cocoon://get-file/' + @path)"/>

          

this should of course be

<xsl:copy-of select="document(concat('cocoon://get-file/', 

        

@path))"/>

    

instead of

   <xsl:copy-of select="document(@path)"/>



Cocoon reads the catalog and does not complain, so at 

          

least I have 

    

it working now.



I was wondering (1) if this is expected behaviour (2) if there is 

another, more elegant way to solve this: can the XSLT 

          

processor be 

    

instructed to read the catalog somehow?



Jan Willem Boer

http://www.linkedin.com/in/janwillemboer

          



      

---------------------------------------------------------------------

    

To unsubscribe, e-mail:  [EMAIL PROTECTED]

For additional commands, e-mail:  [EMAIL PROTECTED]







      

    



---------------------------------------------------------------------

To unsubscribe, e-mail:  [EMAIL PROTECTED]

For additional commands, e-mail:  [EMAIL PROTECTED]







  


Reply via email to