[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: concur
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC