Kohsuke KAWAGUCHI wrote:
> > - I think people will want to layer type assignment on top of TREX.
> > It's hard to make type assignment work for concur.
>
> It's not completely right. When one does type assignment, one can simply
> concentrate on reporting types of one branch, and forgets about the
> others.
That's the strategy I've adopted too.
> In fact when <concur> is used for exclusion, this strategy works fine.
But it totally fails to work for other uses of <concur> (eg multiple
namespaces).
One really needs a strategy that will make
<concur>
<data type="xsd:int"/>
<anyString/>
</concur>
yield a type assignment of xsd:int, regardless of the order of the two
subpatterns of <concur>.
> > - It's quite tricky to implement (especially getting coherent error
> > messages).
>
> <concur> is not the only one.
> <interleave> also severely restricts applicable algorithms.
> Automaton-based implementation will be impossible due to <interleave>.
A couple of comments:
1. I don't agree that <interleave> makes automation-based
implementations impossible; it just means you have to construct
automatons lazily. (In fact, you can view the "derivative"-based
approach in JTREX as lazily constructing a kind of automaton where
states are represented by a canonical representative of the patterns
that match the remaining input.)
2. At least in JTREX, <interleave> is no harder to implement than
attributes. In JTREX, I pretend that attributes are ordered lists
rather than bags, and pretend that <group> for attributes means
<interleave>.
3. The functionality provided by <interleave> is very important.
James
