On Oct 16, 2008, at 5:47 PM, Dominique Devienne wrote:
On Thu, Oct 16, 2008 at 1:48 PM, Robert Koberg <[EMAIL PROTECTED]> wrote:
Actually, there is more. You will want to check all document
functions to
see what other is being used and if it has changed. I actually have
something like that, but it works off a hierarchical config file
(something
like what apache forrest uses but more recursive in orientation)
that is not
really.
Ah ah, indeed, I didn't think about doc() calls. But aren't these
dependent on variables, and the primary XML document's content
possibly, while the import/include must use URLs only, possibly
dependent on params only?
I'm no expert at XSLs, but just dealing with import/include would
already be an improvement.
Instead of parsing the XSL, I use 2 custom URIResolvers to gather the
dependent files and put that into a cache entry object.
This is smart! you're intercepting the calls to discover which
resources are used. You must then keep a cache in the filesystem then
though. (there's already a cache impl linked to <uptodate> I think).
While you're at it, why not find out which result document(s) were
generated, especially is XSLT 2.0 where it's no longer an extension
and part of the language?
That is really not a problem either, at least for saxon (and we really
don't have any other choice...). Saxon exposes a a similar resolver
interface for output :)
http://saxonica.com/documentation/javadoc/net/sf/saxon/OutputURIResolver.html
best,
-Rob
Just kidding, <javac> doesn't compile a file
if the generated .class for an inner class are been removed, that's
the same kind of limitation.
Thanks for the precision Rob. --DD
---------------------------------------------------------------------
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]
