Completed

• schema all disallow empty strings

• Custom parser setters all do explicit conversion via SpringSupport and StringSupport

• all parameters stay as primitives.

Additionally I put some extra care around regexp handling which might have previously silently succeeded and may the support code strictly support the XML spec (allowing only 1/0/true/false).

The decision in the team meeting 19/Jul is to

• Back out the tolerance for null Booleans in configuration (i.e. revert to the primitive setters only)

• To continue to use the {{SpringSupport.getStringValueAsBoolean }}method _in customer schema parsing_ to feed these operations (so as to allow eventual control over what exactly is true and false for XML.

Happy to add it to the list for Friday.  But for the record, the case we end up stressing about is

attrib=" " or attrib="%{property}" where property is defined but empty - both of these pass the schema.

Currently Spring converts both of these into a null of type Boolean and then blows up trying to assign that to a boolean primitive.

My first attempt was to change the boolean parameter to Boolean, but Brent worried about the non-orthogonality of the setter and the getter.  The next attempt was to add a setter of the same name but different type.  But in these cases Spring still tries to call the setter which takes the boolean (primitive) parameter.  So we are left with two options

• Give up.  Change the schema and be done with it.  After all noone has complained.

• Add a new setter with a distinguished name.  This works and passed all the tests, but I'm also concerned that we are well past the place of diminishing returns. OTOH this also provides help if needed in the native spring format.

At this stage it would take very little to flip my opinion from doing the second to doing the former (revert all the changes so far except to the schema).

As a final wrinkle, all of these cases actually end up on Boolean.valueOf and I'm not convinced that that is necessarily the right thing for XML.

We can discuss Friday, I'm not sure of the purpose of adding these additional setters. We generally haven't used Booleans in setters across the APIs, and I can't think why we'd need to given that null isn't meant to be allowed in the schema anyway.

Pushed changes for afs:, sec: and resolver:

metadata: still pending.