Validating XML and SAML Objects
Traditionally, OpenSAML has required XSD-based schema validation of XML in order to unmarshall reliably. While this is still supported, it is understood that this is bothersome to a lot of implementers and is no longer a requirement. With the move to a more mechanical unmarshalling process and a lot of extra data structures to track child objects, the code can handle invalid XML without crashing or requiring a lot of excess runtime checking. The cost of this is basically memory over the cost of validation in the parser.
The new library leaves this decision to the application, but since the memory penalty is inherent in the new design, it's probably a given that people won't validate while parsing any more.
As a supplemental tool, the XMLTooling layer includes support for executing
Validators against any XMLObject.
Validators can execute any const operations against an XMLObject to determine its fitness for some purpose. This includes but isn't limited to basic structural checking.
The most common way to perform informal structural validation is to use a
ValidatorSuite . A suite contains a number of validators, each registered against a particular element name or type. A suite can be executed against an XMLObject, and the entire tree will be traversed. Each node will be examined, and any
Validators registered for it in the suite will be run.
A global object called the
SchemaValidatorSuite is available for executing structural integrity checking of all known object types. This is not a substitute for real schema validation because that would be redundant. However, you can be fairly sure that objects you create by hand that pass will probably be acceptable to most consumers.
Stand Alone Validation
Alternatively, you may wish to execute stand-alone instances of classes that support the
Validator interface directly against particular objects. Any kind of profile or business logic can be encapsulated in this fashion. This is usually more efficient than walking an entire tree.