cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Studley <>
Subject RE: Inserting / Comining XML data
Date Thu, 06 Dec 2001 11:59:47 GMT
Ah yes sorry - I missed the bottom part of the previous mail in my original

... As Karl rightly points out this is pure XSLT/JAXP stuff, I don't use
Xalan I use Saxon and it works just the same.

Thinking about this more in terms of cocoon, maybe the best way of utilizing
this sort of method is rather than to try and use it within logic sheets (if
at all possible) to have a 2 layer transformer, e.g.

<!-- Feed in your static XML -->
<map:generate src="docs/{1}.xml"/>
<!-- Transform in your dynamic XML fragments using the document() function
<map:transform src="stylesheets/business_funcs.xsl"/>
<!-- Final styling transformation of resultant XML to HTML etc. -->
<map:transform src="stylesheets/simple-xml2html.xsl"/>

So in effect you use this mechanism in place of XSP - although you are still
able to use that as well as your original source!

Do the newly registered protocols work within the sitemap as well? If they
do you could get really silly and do sensibly:
<map:transform src="http://stylerepository:9090/mystyle.xsl"/>
or crazily
<map:transform src="dynamic-styles://generate-4-customer/Larry.xsl"/>
where you could dynamically generate (and cache) a stylesheet for a specific
use which could compile in relevant rules and wotsits. A bit over the top -
but could be used to effectively produce custom on the fly pre-compiled

All the best


-----Original Message-----
From: Karl Øie [] 
Sent: 06 December 2001 11:18
Subject: RE: Inserting / Comining XML data 

points missed again, sorry! :-)

1: javax.xml.transform.Transformer has a setURIResolver(), so this is not
adding stuff to xalan, this is using the javax.xml api.

2: it would NOT tie things down to xalan as ... again this is using the
javax.xml api.

3: as i wrote in my email response to luke's orriginal request; the cocoon
does not accept annything else than char/byte streams as source-handlers,
javax.xml does. http is only a byte/char-stream and sometimes that might not
be enough.

mvh karl øie

>I've been following this discussion.  This is not rambling, the concept
>works.  I've done it before using http:  That is, created a URIHandler or
>something similar, but then wrapped it in a servlet and made sort of an XML
>XPath requester that loads stuff from a database.  However, I think Robs
>point is that pretty most anything you'd want to do with a URIResolver
>class, you could also do with http: (i.e. a servlet)  So the calls might be
>(I think you could probably even get the "http:localhost/serv" put
>else so they would have to know that, but I'm not sure how...)
>The XSL processor would then go get it if you used "document()".  And
>a problem with the way you're viewing it I think.  The "document()"
>is part of the XSL processing (Xalan), not part of cocoon as far as I can
>tell.  Now, you might be able to add stuff to Xalan, but then your XSL
>be tied to it.
>Unless you're talking about in the sitemap.xmap file.  This get XSLTed down
>to java, compiled, and run so presumedly it's handled a different way.

Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message