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

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

> 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.

E-Mail: k-kawa@bigfoot.com

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

Powered by eList eXpress LLC