Re: [relax-ng] Comments on the compatibility spec

[MURATA Makoto <EB2M-MRT@asahi-net.or.jp>]

> > 2. Ambiguity
> >
> > Most readers will find it difficult to understand the ambiguity
> > problem.  Therefore, I would propose editorial changes as well as
> > small technical changes.
> 
> I would rather not make substantial editorial changes at this very late 
> stage.  Also I think your proposed changes would give a undue degree of 
> prominence to the ambiguity issue.

Althouth my proposal requires a new section (probably section 3), I don't think 
that it is hard to incorprate it.  Probably, your biggest concern is the prominence 
of the ambiguity issue.

Do people understand the ambiguity issue?  In its current form, the introduction 
of this spec is not easy to understand.  I would like to make the issue 
clear to everybody rather than hiding it.

> The problem is that schema simplification does not preserve element 
> identity.  

OK.

> > 4. Minor
> >
> > 1)
> >
> > The first para and the second para in the introduction should be
> > swapped?
> 
> The second para refers to "these extensibility mechanisms", which wouldn't 
> make sense without the preceding bullet points.

We can simply omit "the" and the first para?  (I am concerned about lack of 
clarity of the introduction.)

> > 2)
> >
> > A below table in Section 3 would help.
> >
> >
> >         compatibility  soundness  infoset-modification
> >
> > default      X            -              X
> >
> > ID           X            X              X
> >
> > doc          X            -              -
> 
> If you want to mark it up, I'll put in in.

OK.  I'll mark it up.
 
> > 3)
> >
> > Section 4 introduces "a:defaultValue" without explaining what the
> > prefix "a" refers to.  However, strictly speaking, Section 1 merely
> > states that "EXAMPLES in this specification ..".
> 
> I think  we can just delete "Examples in" from that sentence in Section 1.
> 
> > 4)
> >
> > In the forth bullet in the itemized list in Section 5, we have "its
> > parent attribute element".  James probably mentions another attribute
> > element having the same ancestor element element.
> 
> I don't understand this comment.

What do you mean by "any ATTRIBUTE element that competes with its parent ATTRIBUTE 
element has an DATA or VALUE child specifying a datatype associated with the same ID-type."?

BTW, "an" should read "a".

Cheers,

Makoto