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: [relax-ng] Re: attribute constraint



Wait, allowing oneOrMore//choice//attribute//(anyName|nsName) is
non-trivial, I guess.

As murata-san said, Hosoya-san's proof assumes what I wrote in the
current issue list.


By allowing <choice>, we can have content models like:

<oneOrMore>
  <choice>
    <attribute>
      <nsName ns="A"/>
    </attribute>
    <attribute>
      <nsName ns="B"/>
    </attribute>
  </choice>
</oneOrMore>

the normal form (that conforms to hosoya-san's assumption) of the above
is:

<choice>
  <group>
    <oneOrMore> attA </oneOrMore>
    <choice>
      <empty/>
      <oneOrMore> attB </oneOrMore>
    </choice>
  </group>
  <group>
    <oneOrMore> attB </oneOrMore>
    <choice>
      <empty/>
      <oneOrMore> attA </oneOrMore>
    </choice>
  </group>
</choice>

It looks like it's always possible to remove <choice> inside <oneOrMore>.
Did we prove that?



>  if an <attribute> occurs in a <oneOrMore>, then its first 
> child must be <nsName> or <anyName>.

I think it's always possible to remove <oneOrMore> if the attribute
inside it has a finite name class. So contextual restriction doesn't
necessarily impose this as a constraint.


regards,
--
Kohsuke KAWAGUCHI                          +1 650 786 0721
Sun Microsystems                   kohsuke.kawaguchi@sun.com



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


Powered by eList eXpress LLC