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: Prohibiting duplicate attributes.


Kohsuke KAWAGUCHI wrote:

> Murata-san suggested to me that restricting duplicate attributes (see
> the issue #21) is a good thing in several ways.

Thanks for starting this thread on behalf of lazy M-san.

First, let's consider some examples of errors.

Kohsuke KAWAGUCHI wrote:

> For example,
> 
> <group>
>     <attribute name="foo"/>
>     <attribute name="foo"/>
> </group>
> 
> is an error.

Yes.  This is an error, since @foo matches both <attribute/>.

> <group>
>     <attribute name="foo"/>
>     <attribute>
>         <anyName/>
>         ...
>     </attribute>
> </group>
> 
> is also an error.

This is also an error, since @foo matches both.

Here is slightly more complicated example

<group>
  <choice><attribute name="a"/><attribute name="b"><empty/></choice>
  <choice><attribute name="b"/><attribute name="c"><empty/></choice>
</group>

Again, this is an error.  @b matches both <choice/>.  If this example had 
<interleave> rather than <group>, we had the same error.

<group>
  <oneOrMore><choice><attribute name="a"/><attribute name="b"><empty/></choice></oneOrMore>
  <choice><attribute name="b"/><attribute name="c"><empty/></choice>
</group>

is also an error.

Intuitively speaking, my proposal is as follows:

	Given <group> p1 p2 </group> or <interleave> p1 p2 </interleave>, a
	single attribute never matches an <attribute> occurring in p1 as well
	as an <attribute> occurring in p2.

This restriction allows eager construction of hedge automata 
even for attribute-element content models (no combinatory 
explosion).  More about this, see my next mail.

Now, I present my algorithm for detecting duplicate attributes.  I assume 
that we have boolean operators for name classes and that we cant test 
emptyness of name classes.

As usual, I assume that the pattern is already in the normalized form.  
Furthermore, I assume that restrictions on <oneOrMore> and <list> are 
checked elsewhere.

Here is the algorithm.

proc checkDuplicatedAttributeDcl(pattern p) returns nameClass {
switch (p) {

   case <attribute>nc p1</attribute>:
       return nc;

   case <group>p1 p2</group>:
   case <interleave>p1 p2</interleave>:
       nc1 = checkDuplicatedAttributeDcl(p1);
       nc2 = checkDuplicatedAttributeDcl(p2);
       if the intersection of nc1 and nc2 is NOT empty then
          print "duplication of attributes"
       fi
       nc3 = the union of nc1 and nc2;
       return nc3;

   case <choice>p1 p2</choice>:
       nc1 = checkDuplicatedAttributeDcl(p1);
       nc2 = checkDuplicatedAttributeDcl(p2);
       nc3 = the union of nc1 and nc2;
       return nc3;

   case <oneOrMore>p1 </oneOrMore>:
       nc1 = checkDuplicatedAttributeDcl(p1);
       return nc1;

   case <list/>: //I suppose that <list> does not contain subordinate
                 //<ref> or <attribute>.
   case <value/>:
   case <data/>:
   case <text/>:
}


Cheers,

Makoto


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


Powered by eList eXpress LLC