[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [relax-ng] Re: Interleave and text
> I have been trying to figure out whether we need to make it an error if
> <text/> occurs in both operands of an <interleave/>. So far I haven't had
> much success. I haven't been able to construct an example that causes Jing
> to blows up nor have I been able to convince myself that it is impossible to
> construct such an example. Help!
I now believe it's OK to have multiple texts in both branches of an
interleave. Here is the informal proof:
The property that we need to preserve here is:
given an token (element,attribute or character literal), it has to be
always possible to uniquely determine the patterns that consume the
token.
Assume the current residual R = <interleave> ... </interleave> and the
current token is a character literal. Say R contains <text/>.
According to the contextual restriction, we don't have <data/> or
<value/> in R.
If R cannot accept this token, then the above property is preserved
This happens for R like
<interleave>
<group>
<element name=X/>
<text/>
</group>
<group>
<element name=Y/>
<text/>
</group>
</interleave>
If R can accept this token, then there must be one or more <text/> that
can match it. If there is only one, then again the above property is
preserved, so it's OK.
So the problem is when we have more than one <text/> that can match it.
To see why it's OK, it helps to look at a problematic interleave:
<interleave>
<group>
<element X>
<element Y>
</group>
<group>
<element X>
<element Z>
</group>
</interleave>
Why this interleave is a problem? Because when we see X, there are two
ways to consume it, and the residual varies depending on it.
Now in case of <text/>, <text/> has the unique property that it's not be
"consumed". That is, while residual(<element>,ElementToken) = <empty/>,
residual(<text/>,CharacterToken) = <text/>.
So even though there are two ways to consume it, the residual always
remains the same regardless of matched <text/>. So we can always match
the character token to all matchable <text/> and this doesn't change the
semantics.
Q.E.D.
regards,
--
Kohsuke KAWAGUCHI +1 650 786 0721
Sun Microsystems kohsuke.kawaguchi@sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC