> Editorial changes will significantly improve 7.1 and I have suggested them
already.
> I am going to implement my proposal this weekend.
>
> http://lists.oasis-open.org/archives/relax-ng/200107/msg00190.html
I think we should explore alternatives to using a single, mega-BNF to
describe all the restrictions. One possibility is to introduce the concept
of an excluded path. For example, if
nsName/except//nsName
is an excluded path, then the normalized grammar cannot contain an nsName
element that has an except child that has a nsName descendant. Then 7.1
implies the following excluded paths:
attribute//element
attribute//attribute
list//list
list//element
list//attribute
list//text
key//key
key//keyRef
key//list
key//element
key//attribute
key//group
key//interleave
key//oneOrMore
key//text
anyName/except//anyName
nsName/except//nsName
nsName/except//anyName
oneOrMore//group//attribute
oneOrMore//interleave//attribute
(Have I missed any?)
The one thing we can't do with this notation is the restriction on <group>,
<interleave> and <oneOrMore> applied to <data> and <value>. Suppose we use
the notation:
foo - bar
to indicate something that matches foo but doesn't contain any bar
descendants. Then I think this restriction can be described by saying that
the content of a group or interleave element not inside a list element must
match
(pattern - data - value) (pattern - data - value)
| pattern (pattern - text - data - value)
| (pattern - text - data - value) pattern
Or maybe we can use inference rules for this.
James
