>> > Add support for xml:id What kind of support is needed?
>
> Nothing in the RELAX NG specification. However, the xml:id
> recommendation recommends validation of xml:id
> against xsd:ID  (see D.3 With RELAX NG Validation in the
> xml:id recommendation).  People will then have to  follow the
> DTD compatiblity specification, which imposes severe
> restrictions on unambiguity.

Well, I think part of the answer is to educate people that the DTD
compatibility specification is optional and you don't have to follow
it.  In particular, if you are using schemas that are more expressive
than DTDs, then you probably don't want to follow it.  Another good
reason to make Jing by default not enforce the DTD compatibility
specification for ID/IDREF.

> I now think that the best solution is to create an independent
> specifcation dedicated to identity constraints.  Unfortunately,
> SC34/WG1 has achieved nothing about it.

A long time ago, I started writing some code for this:

http://code.google.com/p/jing-trang/source/browse/trunk/mod/picl/src/main/com/thaiopensource/validate/picl

with a schema here:

http://code.google.com/p/jing-trang/source/browse/trunk/mod/picl/src/main/com/thaiopensource/validate/picl/resources/picl.rnc

But I don't remember much about it.

>> > Align with WXS datatypes 1.1
>>
>> Probably.  Does anything have to be done on the spec front?
>
> Perhaps, we should revise
> "Guidelines for using W3C XML Schema Datatypes with RELAX NG"?

Yes.

>> > Lifting restions on interleave -- list//interleave (10.2.4) should be 
>> > allowed, and "10.5 Restrictions on interleave" should be removed.
>>
>> The restrictions are a pain, but do we know algorithms that will allow
>> validators to be robust/performant in the absence of these
>> restrictions?
>
> As far as I know, none of the RELAX NG implementations take
> advatage of this restriction.  We should request feedbacks from
> implementors.

I thought the point was that the cases that made Jing blow up couldn't
happen any more because they were disallowed by the interleave
restriction. When you compute the derivative of an interleave with
respect to a start-tag open, then the restriction ensures that all but
one of the choices will be notAllowed.

James

Reply via email to