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

[James Clark <jjc@jclark.com>]

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

My main concern is about the timing.  The things your are proposing to 
change were part of the specification that we voted to approve as a 
Committee Specification and are substantially unchanged for more than 3 
months.  You first raised these issues one week before we plan to release 
the final spec.  This is the time for proof-reading, fixing typos, and 
tweaking formatting not for substantial presentational changes.

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

I don't think users need an in-depth understanding of the ambiguity issue. 
It is sufficient if they have the superficial understanding that

  "it may be ambiguous which
  <literal>element</literal> or <literal>attribute</literal> pattern any
  particular element or attribute in the instance matches"

This is a spec not a tutorial on technical issues in the design of XML 
schema languages.

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

I think that will cause unclarity later on in the following paragraph:

"Some features of XML 1.0 DTDs, in particular default attribute values and 
ID/IDREF/IDREFS validation, depend crucially on this unambiguous 
correspondence between elements or attributes in the instance and their 
corresponding declarations. In order to support these features in RELAX NG 
schemas by means of datatypes and annotations, it is therefore necessary to 
impose restrictions on the use of these datatypes and annotations."

For this paragraph to make sense, we need to say that the extensibility 
mechanisms of RELAX NG are datatypes and annotations, which is what the 
first para of the intro says.


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

"it" refers to the same thing in this bullet as in the first two bullets in 
the list, namely the <data> or <value> element whose compatibility is being 
checked.  I am not sure exactly what you find unclear here. Does this help

"if its ATTRIBUTE parent has any competing ATTRIBUTE elements, then each 
such competing ATTRIBUTE element has a DATA or VALUE child specifying a 
datatype associated with the same ID-type."

? Also maybe swap the 3rd and 4th bullets so that the bullets applying to 
the parent attribute element are together?

James