[relax-ng] Time of checking of context-independent constraints

[James Clark <jjc@jclark.com>]

In the course of implementing the new section 7.4 with the constraints on
xmlns attributes, I encountered on awkwardness relating to the time at which
the constraint is checked.

Because it is in 7.4 it applies to the simplified schema.  This means that
the constraint is checked only *after* unreachable definitions have been
removed (by 4.18) and after patterns that are impossible because of
notAllowed are removed (by 4.19).

This implies that whereas

<element name="foo">
  <attribute name="xmlns"/>
</element>

is illegal, something like:

<element name="foo">
  <optional>
    <notAllowed/>
    <attribute name="xmlns"/>
  </optional>
</element>

is legal (because the attribute element gets simplified out).

This is a bit of a pain from an implementation point of view.  Since the
constraint in 7.4 doesn't depend on resolving references, it makes to sense
to check it as soon as possible during parsing, rather than later after
references have been resolved. However, the spec doesn't allow this.

There are similar issues with 7.1.6.  For example, this is legal:

<element name="foo"
          datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
         xmlns="http://relaxng.org/ns/structure/0.9">
  <optional>
    <notAllowed/>
    <attribute>
      <anyName>
        <except>
          <anyName/>
        </except>
      </anyName>
    </attribute>
  </optional>
</element>

(although Jing currently gives an error for it).

Another related issue is checking related to datatypes:

- checking whether parameters are legal
- checking where a particular datatype local name is present in a particular
datatype library

The spec isn't clear about when these are checked, but I guess most people
would interpret it as saying they are checked after simplification.  This is
pain because it means that you can't build the datatype during parsing: you
have to construct some sort of representation of the parameter list, and
then build the datatype later.

Possible solutions are:

- do nothing (except say explicitly that datatype checking is done after
simplification); implementors will just have to deal with the awkwardness

- introduce a new section somewhere between 4.10 and 4.18 that checks for
context-independent constraints (ie constraints that don't depend on
resolving refs), specifically constraints on attribute names that are really
namespace declarations (7.4), datatype usage (6.2.8), except in name classes
(7.1.6).

James