OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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