By default Jing should not enforce DTD compatibility spec for ID/IDREF/IDREFs

[GoogleCodeExporter]

By default, Jing currently enforces the constraints of the DTD 
compatiblity spec for ID/IDREF/IDREFS datatype, and you have to use -i to 
turn it off.  The DTD compatibility spec has very restrictive constraints 
on ambiguity which are often inconvenient.  It is particularly problematic 
if people (not unreasonably) declare xml:id to be of type ID: it makes no 
sense at all to enforce the DTD compatibility spec for xml:id attributes, 
because you can tell they are IDs just from their name.

Original issue reported on code.google.com by jjc.jclark.com on 4 Nov 2008 at 4:32

[GoogleCodeExporter]

Original comment by jjc.jclark.com on 7 Nov 2008 at 3:02

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

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.

Original comment by alex.bro...@gmail.com on 14 Jan 2009 at 10:38

[GoogleCodeExporter]

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.

Original comment by jjc.jclark.com on 16 Jan 2009 at 8:24

[GoogleCodeExporter]

Some more thoughts here:

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

Original comment by jjc.jclark.com on 17 Jan 2009 at 7:35