Re: concur

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

First of all, I welcome throw-away of <concur>. This makes RELAX and
TREX much closer, doesn't this  :-)


> But it totally fails to work for other uses of <concur> (eg multiple
> namespaces).

That's true. But As you mentioned, <concur> is typically used as
exclusion. So this strategy covers 80%, which is fine.


> 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

I'm sorry I used a wrong word. I meant "compilation into automaton is
impossible".

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

And this is quite understandable. And I know that we cannot throw away
<interleave> as long as we want uniform treatment of attributes and
elements. So I think there is no point in describing how bad
<interleave> is, but still...


Lazy evaluation is good in some cases, but it also has several problems.

* When one schema is shared among several threads, synchronization is
  necessary, which severely hits the performance. This situation is very
  common in the business application where tons of incoming orders have to
  be validated.
* In a long run, the table which memorizes patterns blows up. JTREX
  suffers this problem, too.



regards,
----------------------
K.Kawaguchi
E-Mail: k-kawa@bigfoot.com