[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Issue: <element>&<attribute> in <list>
Allowing this seems unnecessarily confusing. The semantics of <list> p </list> should be that it matches a **string** that when split into tokens matches p. I seem no point in allowing somebody to write: <element name="foo"> <list> <attribute name="bar"/> </list> </element> and having it match: <foo bar="baz"/> It makes it harder to explain what <list> means. If we decide that it does not match, then we need to decide whether it is an error or not. With the current formal semantics, any use of <attribute> inside <list> is equivalent to <notAllowed>. This is a similar issue to use of <element> and <attribute> inside <element>. With the current formal semantics, any use of <element> or <attribute> inside element is equivalent to <notAllowed>. I think we should decide these consistently. I strongly dislike allowing <element> inside <list> with the semantics you suggest. I think it's fundamentally wrong for a particular element to simultaneously have as children typed content (ie something that matches <data>) and elements, eg <foo>123<bar/></foo> where 123 matches <data type="int"/> rather than <text/>. This is the same reason why I want a stronger restriction than you on mixing elements and data. ----- Original Message ----- From: "Kohsuke KAWAGUCHI" <kohsuke.kawaguchi@eng.sun.com> To: "Murata Makoto" <mura034@attglobal.net> Cc: <relax-ng@lists.oasis-open.org> Sent: Wednesday, June 13, 2001 12:30 AM Subject: Re: Issue: <element>&<attribute> in <list> > > 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 > > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: relax-ng-request@lists.oasis-open.org > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC