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: What exactly is prohibited by the constraint of RELAX NG?


I've mean struggling over the weekend to find a way to express our good
constraints.  The best way I've found so far is to transform into the normal
form described at:

http://lists.oasis-open.org/archives/relax-ng/200104/msg00046.html

and then use a grammar to describe restrictions on that normal form.

The normal form is as follows (grammar is the start symbol):

grammar = <grammar> start define* </grammar>

start = <start> top </start>

define = <define name="NCName"> <element> nameClass top </element> </define>

top = <notAllowed/> | patternOrEmpty

patternOrEmpty = pattern | <empty/>

pattern = <text/>
          | <data ...>...</data>
          | <value .../>
          | <list> patternOrEmpty </list>
          | <attribute> nameClass patternOrEmpty </attribute>
          | <ref name="NCName"/>
          | <oneOrMore> pattern </oneOrMore>
          | <choice> patternOrEmpty pattern </choice>
          | <group> pattern pattern </group>
          | <interleave> pattern pattern </interleave>

This incorporates a couple of tweaks relative to the referenced message.
I've restricted <empty/> to be the first child of <choice> (it simplifies
the restriction).  Also I have permitted <notAllowed/> as a child of
<element/>.  It turns out to be tricky to get rid of this case because of
the possibility of recursion.

The restriction on pattern is that it must be in the language generated by
the following grammar (which is a subgrammar of the above grammar). Note
that the following grammar is ambiguous.  (It is inconvenient and
unnecessary to disambiguate it.)  Obviously, this doesn't handle the
constraint on duplicate attributes (which is relatively straightforward) nor
on unambiguity of key/keyRef (which is not so straightforward).

pattern ::=
    attributeGroup
    | value
    | repeatable
    | <choice> pattern pattern </choice>
    | <choice> <empty/> pattern </choice>
    | <group> attributeGroup pattern </group>
    | <group> pattern attributeGroup </group>
    | <interleave> attributeGroup pattern </interleave>
    | <interleave> pattern attributeGroup </interleave>

attributeGroup ::=
    singleAttributeGroup
    | <oneOrMore> singleAttributeGroup </oneOrMore>
    | <group> attributeGroup attributeGroup </group>
    | <interleave> attributeGroup attributeGroup </interleave>
    | <choice> attributeGroup attributeGroup </choice>
    | <choice> <empty/> attributeGroup </choice>

singleAttributeGroup ::=
    <attribute> nc value </attribute>
    | <attribute> nc <empty/> </attribute>
    | <choice> <empty/> singleAttributeGroup <attribute>
    | <choice> singleAttributeGroup singleAttributeGroup <attribute>

repeatable ::=
    mixed
    | singleAttributeGroup
    | <choice> repeatable repeatable </choice>
    | <choice> <empty/> repeatable </choice>
    | <oneOrMore> repeatable </oneOrMore>

mixed ::=
    <ref name="name"/>
    | <text/>
    | <group> mixed mixed </group>
    | <interleave> mixed mixed </interleave>
    | <choice> mixed mixed </choice>
    | <choice> <empty/> mixed </choice>
    | <oneOrMore> mixed </oneOrMore>

value ::=
    string
    | <list> tokens </list>
    | <list> <empty/> </list>
    | <choice> value value </choice>
    | <choice> <empty/> value </choice>

tokens ::=
    string
    | <oneOrMore> tokens </oneOrMore>
    | <group> tokens tokens </group>
    | <interleave> tokens tokens </interleave>
    | <choice> tokens tokens </group>
    | <choice> <empty/> tokens </group>

string ::=
    <text/>
    | <data ...>...</data>
    | <value .../>







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC