[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Improving 7.1
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC