Re: [relax-ng] What's ambiguous for Relax NG?

["MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp>]

> Do you mean that regular expressions do not "cross the boundary of
> elements", ie that you don't have element patterns in regular
> expressions but only combinations of references to element definitions
> while the regular hedge grammar is the whole Relax NG grammar?

Right.

> > (By the way, restrictions on <interleave> is for another type of 
> > determinism.)  As for data binding tools, I think that different 
> > data binding tools require different types of unambiguity 
> > of regular expressions.
> 
> Do they require determinism or just unambiguity? I think that's the
> question which made me start the thread.
> 
> I'd say that what's important for them is that the type assignment gives
> a consistant result after each run. Isn't unambiguity enough for this?

It depends.  For example, in the case of Relaxer, determinism is required 
when you use SAX while unambiguity is enough (thanks to backtracking) when 
you use DOM.  To be precise, even when your schema is ambiguous, Relaxer 
chooses one of the  possible interpretations as long as you use DOM.  I am 
very sure JAXB requires different types of unambiguity, since, in the default 
mode of JAXB, internal structures of regular expressions are not captured 
by Java classes.  (Kohsuke, correct me if I'm wrong.)  I conjecture that 
RelaxNGCC requires another.  Another data binding tool (for DTDs), namely 
XP++, does not require determinism or unambiguity.

http://www.alphaworks.ibm.com/tech/xmlprocessingplusplus

> I am wondering if we do not find here the difference you made between
> regular expressions and regular hedge grammar: after simplification, my
> example wouldn't have any ambiguous regular expression but the resulting
> grammar would be ambiguous. 

Most data binding tools (at least, Relaxer and RelaxNGCC) avoid simplification, 
since some important information for data binding is lost after simplification.

> Also, the whole question could be ruled out with a statement specifying
> which alternative should be taken if we have two choices matching a
> node. If we just said that the "first" one would be taken for type
> assignment, ambiguous grammars wouldn't be ambiguous any longer for
> "type assigners" (and other classes of validators wouldn't have to
> bother with this rule).

It is an interesting idea to create another spec for the precedence 
rule of possible type-assignments.  On the other hand, I think that such 
a specification should not count on simplification.

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>