Re: Issue: <element>&<attribute> in <list>

[Kohsuke KAWAGUCHI <kohsuke.kawaguchi@eng.sun.com>]

> Let's consider three positions in my mail at:
> 
> http://lists.oasis-open.org/archives/relax-ng/200106/msg00127.html

OK.

Whatever position we adopt, we can allow <attribute>s within a <list>.
If we change the formal semantics of list to the following one,

E; ns |- a; split(s) =~ p => k;kr
---------------------------------
E; ns |- a; s =~ <list> p </list> => k;kr

then we can allow <attribute>s in a <list>. If the language generated by
p is within the XML1.0 model, then so does <list>p</list>.

The implementation is also easy. The attached algorithm can correctly
implement the above semantics.



For <element>s in a <list>, we didn't have an algorithm to implement
<element>s in a <list>. That's why I suggested to prohibit it. But
actually, I found it while I'm writing this. The attached algorithm is
also capable of properly implementing what you expect.



> In position 2, we disallow both <element> and <attribute>.  Since position 2 is 
> my favorite, I would like to disallow them in <list>.

I still don't think <element>/<attribute>s in a <list> is beyond the
regular language. Would you show me an example of such a case?




* modified algorithm for <list>

function residual( <list> P </list>,  S ) {
   if( S is a string token ) {
     Let {t1,t2,..., tn} be tokenization of S.
     
     return <list>
       residual( residual( residual( P, t1 ), t2 ) ..., tn ) </list>
   }
   if( S is an element token ) {
     return <list> residual(P,S) </list>;
   }
   if( S is an attribute token ) {
     return <list> residual(P,S) </list>;
   }
   throw new AssertionFailure();
}





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