Sorry, for taking that long to come back, Scott Sanders <[EMAIL PROTECTED]> wrote:
> I agree that xpath is generic, but my idea of an xpath task would be > nothing on the main element, and then many different types of > subtasks, such as replace, set a property, check a value, etc. I didn't mean to kick off the creation of a more generic task, I was just concerned that the name xpath would be too generic for what it does. If you want to extend it to be that generic, fine. An alternative would be to find a better name and keep the current implementation 8-) > If that happens, does it make sense to still move the replace > functionality to <replace>, or to keep all functionality that uses > xpath under the same task? I depends on how you think about these tasks - I'd rather group tasks by what they do (replace, set properties, whatever) than how they do it. Using this approach there wouldn't be much room for a generalized xpath task but the functionality had to be spread across several existing tasks. That being said - it really is up to you. I wouldn't veto a generic xpath task and I'd probably commit it sooner or later. You just need to find out, what you really want and need. If replacing is all that is required right now, I'd be happy to simply use a different name for the task like Stephane has submitted it. Stefan
