Data Validation

All this reading about schemas may have made you wonder about validation. For most XML schema languages, it's what the schema is there for to begin with. Within grace, validation is handled by an entirely different class and as a separate step from data translation. The potentially complex wrapping and mangling happening in the translation schemas implemented by the xmlschema class make its schema language less suitable for defining data restraints. For that reason, grace defines the separate validator class that acts upon the native, in-memory representation. A side-effect of this approach is that software using these classes is more liberal in what it will accept from the outside and more strict in what it emits, which is how the internet likes things. The validation process involves itself with a number of restraints that you would want to place on your data:

• Defining mandatory and optional child keys and attributes.
• Verifying mandatory dependencies resulting from optional child keys and attributes.
• Checking the actual data against validation criteria.

Using the validator Class

The validator class uses its own schema language. Such a validation schema can best be seen as a language controlling both iteration over a tree of data and validation of members, attributes and data. As a first example, we will look at a simple record type:

A possible validation schema for such a record could look like this:

As you can see, the <grace.validator> class contains a list of <datarule> objects that can be seen as the validation rules for a single data node. All the child nodes of a given <datarule> object define a criterium and the node is only considered valid if all of them report a positive result. A <match.mandatory> criterium defines a list of mandatory children and/or attributes. If a <mandatory> status is defined for a child or attribute, its absence in the data node will trigger a failure. You can also flag a child or attribute with an <optional> object, which itself can contain one or more <optional> and <mandatory> objects to handle optional objects that trigger mandatory dependencies.

A <match.child> criterium triggers an iteration over all of the data node's child object. The criterium will be evaluated as valid as long as one of the matches is succesful. You can use <and> as well as <or> objects to group together certain conditions. Any of the other matchtypes is also allowed within this context. The <match.rule> object, for instance, is just a command to jump to evaluating the current match against a different <datarule> object. There's nothing stopping you from using these rules inline.

Underneath you will find an overview of the objects involved with the validator schemas, including their attributes and possible child objects.

match.data

Match the object's data against a list of criteria. The child nodes are combined with a logical OR, implying that a minimum of one of the child criteria must match for the data to be considered valid.

If you have a need for multiple data criteria lists to match against you can use the <and>> object to combine multiple <match.data> segments.

match.id

Match the object's key to a value

match.child

Match every child object against a set of rules. The rules are combined with a logical OR, where the validation succeeds if at least one of the child objects returns a positive result.

match.rule

Match object against another <datarule> set.

match.attrib

Match every attribute against a set of rules. The rules re combined with a logcal OR, where the validation succeeds if at least one of this rule's child rules yields positive result.

match.mandatory

Match mandatory sub-objects or optionals with mandatory dependencies.

mandatory

Define a mndatory child object or object attribute with its key.

optional

Define an optional child object or object attribute, with depending sub-rules.