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

[James Clark <jjc@jclark.com>]

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
>
>
>