XPath is a language that handles complex expressions that *can* include document navigation and "query" paths but also contains a lot of other capabilities (consider what you can do with expressions in XSLT: these expressions use XPath with extension functions).
My suggestion is to have Ant register extension functions with the *XPath* context so that they are callable from XPath; however, in my original message I suggested a single (standardized) "call" method that can be used to call any registered Ant task as a catch-all. I also suggested that you *might* want to invoke a target (for some reason) within the expression and that this could be achieved using the document navigation features of the XPath "language" (though what a return value is from a target I don't know other than "success" or "BuildException thrown").
Following your example we could register (again as I suggested) special functions for the "standard" conditionals, so the expression could look like:
${cond: available("file", $myFile, "type", "file")}
1. I'd worry that you are effectively defining a new language -a functional one- inside ant.
2. it doesnt have to be ${}; we would be better using a new symbol like x{}, though again, things will break and we will get accused of having the perl attitude to obscure bits of the keyboard.
3. given that my main issue with xpath, is it possible to plug in new axes for resolving references into the xpath engine we'd use.
4. Is there an xpath engine built in to xerces?
if we could have a new path axis, then we could have references like ant:://myproject/dist ; this would let us resolve using the build file structure, (here a targt called dist in a project called 'myproject') instead of using classic xpath document-centric path resolution.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
