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 > >http://localhost:8082/serve/catalog/cars/* >http://localhost:8082/serve/sales/invoices/0002332 > >(I think you could probably even get the "http:localhost/serv" put somewhere >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 that's >a problem with the way you're viewing it I think. The "document()" function >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 would >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. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
