This has the effect of saying ``when the MICsubmit I am associated with (contained by) is hit, then check this field for errors with respect to its data type.''4.11
The name parameter identifies a field name within the associated fieldspace. Since names of all fields in a given fieldspace must be unique, MIC will know whether the field is dynamic or not. If it is dynamic, then all instantiations of that field present at the time of verification will be checked.
The effect is to call verify() (discussed in the cross interface section, 9.2) on the field contained within the fieldspace. The types of errors caught here are things like `I am supposed to be an integer... am I?' as well as parameter limitation checks, if supported.
The optional ignore parameter will tell MIC to ignore any errors generated directly by this field. Furthermore, it will take the field out of error. This is to allow for the idea that certain submits may change the nature of what we care about and data that was previously in error is no longer in error. Note, however, that any verification will override ignore directives, so combining a vfield tag with an ignore directive and a vinistantiated tag will have the same effect as if the vfield tag were not there at all.
When we say ``generated directly,'' we mean generated by a vfield, vcurrent or vinstantiated. If the field is in error through the agency of an arbitrary verification (kicked off with vverify), then it will remain in error for that reason, even if the ignore directive is called.