minor change to Xmlc taskdef, comments?...

I was going through the Xmlc taskdef to update the docs as requested on the 
list earlier.  However, I saw some inconsistencies.  One that I'd like to 
change, but might affect some people, is changing the "force" attribute to 
take an Xmlc.BooleanType like the other boolean attributes do instead of a 
String.  This shouldn't normally affect anyone if they were using 
true/false values and, in fact, this change will now allow for yes/no 
values to be valid as well (as they weren't recognized before).  However, 
any other string will cause an error in the build.  This affected the 
BarracudaMVC build because ${xmlc.force} was being used, but not always 
present when running the task, so it would error out saying that 
"${xmlc.force}" is not a valid value for the "force" attribute.  This is 
simple to correct by making sure a default value for ${xmlc.force} is 
always set to true/false or yes/no (if the optional force attribute is 
actually used) and allow for overriding in a properties file.

I'm wondering if anyone else has a use-case where this change would bite 
them like it did the Barracuda build.  I can change it back to taking a 
String rather than the Xmlc.BooleanType if need be.  Community 
decides.  Speak up.

Jake