> 2. Restriction of subordinates of <oneOrMore>, that is: "If a <oneOrMore>
> element has an <attribute> descendant, it must not have a <group> or
> <interleave> descendant." [I BELIEVE we voted in favor? Please speak up if
> not!]
We did.
> 3. Datatypes and identity constraints
>
> a. enumeration syntax. Voted in favor of option (b), that is: "Add a
> <value> element. This has a type attribute identifying a datatype." As in:
>
> <value type="xsd:token">foo</value>
>
> or:
>
> <choice>
> <value type="xsd:token">foo</value>
> <value type="xsd:token">bar</value>
> </choice>
Also, the type attribute on <value> defaults to "token".
> c. list of parameters versus a set of parameters. Voted in favor of list
> with the proviso that datatype providers will generate an error if there
is
> a duplicate parameter name, not the RELAX NG implementation.
It *may* generate an error. Alternatively, it may be meaningful. The
interpretation of duplicate parameters is up to the datatype provider.
> 4. combine attribute. Voted in favor of values "choice" and "interleave"
> hence removing the values "group" and "replace". As an attribute of
> <define>, the combine attribute lets you combine duplicate definitions
from
> separate files.
Also, grammar-level includes can contain <define> and <start> elements that
replace the corresponding included definitions.
James
