OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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

One really needs a strategy that will make

  <data type="xsd:int"/>

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

3. The functionality provided by <interleave> is very important.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC