Re: Formal semantics of <text/>

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

I was thinking about data-binding. If <text/> can possibly match the
multiple tokens, then a collection object is needed to store the parsed
result.

But in some cases, <text/> can match at most one token.

<element name="name">
  <text/>
</element>

In cases like this, developers want to have bare String object.

(OTOH, it's not much difficult to decide whether a <text/> can possibly
match multiple tokens, or not).



Another thing is, when I first read your TREX tutorial, I thought
<text/> is just a syntax sugar of <data type="string"/>.

But in fact it's not.  I guess many people will naively assume in this
way and wonder why the following pattern can work as <mixed>.

<interleave>
  <text/>
  ...
</interleave>


It would be easier to understand to have

<interleave>
  <zeroOrMore><text/></zeroOrMore>
  P
</interleave>

as the equivalent of <mixed>P</mixed>.


As for the following pattern and the instance, I rather think that it's
strange for the following pattern to accept the following instance.

> <element name="p">
>   <interleave>
>     <group>
>       <element name="a">...</element>
>       <element name="var">...</element>
>     </group>
>     <group>
>       <text/>
>       <text/>
>     </group>
>   </interleave>
> </element>

>  <p>Open the <a href="#file">file</a>_<var>f</var>.</p>

But I think I'm not strongly pushing on this issue.

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