(No comment was entered for this change.)

I'm not sure this is the whole story: a client of mine using jing very much valued
the ID/IDREF checking in jing because of the detection of duplicate ID values and the
report of broken REFs. Users coming from DTDs expect that kind of checking. What gain
for users is there in turning off such checking by default? (Xerces does not support
xmd:id AFAIK so jing cannot rely on this being done elsewhere).

Certain kinds of ambiguity are also more than "inconvenient". If there is an
expectation to provide onward processing of the document to carry out "infoset
augmentation" as per _RELAX NG DTD Compatibility_ then an attribute that is
ambiguously of type ID cannot be reliably typed, and the warning jing emits are useful.

The gain for users of the change is that Jing would no longer by default reject a
schema that was correct according to the RELAX NG IS.

At the moment, it's very easy to get into a situation where Jing gives an error for a
correct RELAX NG schema:

1. you use xml:id
2. you declare xml:id as type ID (which is what the xml:id Rec suggests)
3. you use a schema that goes beyond the expressive capability of DTDs

The net result is you have a schema that is correct according to the RELAX NG
standard but is not compatible with the RELAX NG DTD Compatibility spec.

There's nothing inherently wrong with this, because the DTD compatibility spec is
optional and there is an easy, appropriate way to perform ID/IDREF checking for
xml:id. xml:id should be checked by a separate module; the whole point of xml:id is
that you can check it _without_ using a schema.

For default attribute values, things are perhaps a bit different: by using the
a:defaultValue annotation, a schema author has arguably shown a clear intention to be
compatible with the DTD compatibility spec.

Some more thoughts here:

http://blog.jclark.com/2009/01/relax-ng-and-xmlid.html