Rule Actions

Revision History
Revision 0.12008-05-25DaveP
Initial Issue

Table of Contents

Actions in general
The validate action
The attach action
Allow (or reject) action

Actions in general

Recall that an action is part of a rule. A rule triggers on a condition (normally a namespace section match) and then carries out the corresponding action. Or actions. Remember that a rule can include a number of actions for each condition. For example, a single section could be validated against a normal schema and be validated against an enclosing schema which has some form of wildcard for the enclosed section. The XHTML schema has this where SVG may be enclosed. Example 7.1 shows an example of this kind

Example 7.1. One condition, two actions

  <rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0">
    <namespace ns="http://www.w3.org/1999/xhtml">
        <validate schema="xhtml.rng" />
    </namespace>
    <namespace ns="http://www.w3.org/2000/svg">
        <validate schema="svg.rng"/>
        <attach/>
    </namespace>
</rules>

This shows the svg section being validated twice. Once against the svg schema and once against the xhtml schema (where it may be wildcarded, to allow anything in the svg namespace, but it does constrain where, in the instance, svg content may be found.


The validate action

The goal is validation so the first one to consider is the validate action, as shown in Example 7.2.

Example 7.2. The validate action

          <namespace ns="http://A">
            <validate schema="a.rng" useMode="B"/>
            <validate schema="sRules.sch"/>
        </namespace>

This rule states that on meeting an element in http://A namespace, (elements remember, the default) the action is to validate the section using a.rng, then sRules.sch, firstly the grammar check, then the Schematron rules. This rule is nice and simple, very straightforward. Having completed the action, a transition is made to some other mode with name value of B

There is a limited way in which validator options may be specified. The option element is a child of the validate element. It takes two attributes. name which is a URI and selects the option known to the validator, and arg which specifies the value. Note that arg is optional, since some parameters to a validator take no values. An example is shown in Example 7.3

Example 7.3. Passing parameters to a validator

<namespace ns="http://www.w3.org/1999/xhtml">
    <validate schema="xhtml.sch">
      <option name="http://www.thaiopensource.com/validate/diagnose"/>
    </validate>
  </namespace>

This limits the parameters - what happens when I use a validator that takes a command line argument such as '-d' to set debug output? I don't know. If the validator option is deemed essential for the action required, then a further attribute, mustSupport with value true is used. The validation fails if the validator does not support this option

The attach action

Rather more subtle than validate. Consider a 'sandwich' construct, in which namespaces A and B are interleaved making a namespace model A/B/A. Each time a section in namespace B is met, an attach action will result in the child section (in namespace B) being attached to the parent section, being the section in the A namespace.

An example where this processing model is useful is to overcome the seperation of an instance into sections. This happens if a single schema combines elements in two namespaces. NVDL processing isolates sections in different namespaces. If this is not wanted then the enclosed sections can be unwrapped to form part of the validation candidate with the enclosing section. Since prior to NVDL this was the only way to validate an instance in N namespaces, this model is likely to be met for some time to come.

NRL, the precursor to NVDL, from James Clark, described attach as a built in mode

<mode name='attach'>
  <anyNamespace>
  <attach/>
</anyNamespace>
</mode>

Using useMode with a value of attach, the same effect will be met. Any sections not in the current modes namespaces will be attached to the parent section.

Allow (or reject) action

Described as a built-in action, this pair are the equivalent of lax or strict validation on the anyNamespace namespace. The result of this action is to permissively validate the section, ensuring a pass, or to reject the content of this section, ensuring a fail. For example, to allow sections in the default namespace we could use

  <namespace ns="">
    <allow/>
  </namespace>

Similarly we could reject any sections in the default namespace by replacing allow with reject in the above example