- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 2 Apr 2006 22:38:30 +0300
On Apr 2, 2006, at 18:56, fantasai wrote: > I'd rather see the id attribute restricted to an NCName token insofar > as possible. We can make an exception for Hixie's repetition > templates, > but otherwise I think it should be compatible with the XML ID syntax. Do you mean common attrs should have a co-occurrence constraint that changes the datatype of the id attribute if the repeat attribute is present? I was planning on defining the datatype of the id attribute as xsd:string { pattern = "\S+" } NCName with the exception that it allows [ and ] will be one huge regexp. (But doable, of course.) If that is what we want, the syntax should probably be (Letter | '_') (NCNameCharWithout02D1and00B7)* (('[' | #x02D1) ( NCNameCharWithout02D1and00B7)+ (']' | #x00B7)))? ( NCNameCharWithout02D1and00B7)* with the XML 1.0 definitions of Letter and NCNameChar. > The concept of "idness" is a useful one for many tools, and even if > browsers don't care what characters there are, other tools do. We > can't > express IDness in a schema if we insist on ignoring its syntactic > restrictions. I didn't bother to make that argument, because I thought changing the language to fit schemas wouldn't go down well with Hixie. :-) (In http://hsivonen.iki.fi/lists-in-attributes/ I tried to bring a general "less code and more reuse of correct code" argument into it instead of only playing the "it's incompatible with my schema language of choice" argument.) I wasn't even expecting to be able to do IDREF integrity checks in RELAX NG. I was planning on doing it in Schematron or Java. Besides, general IDREF integrity checking does not check that, for example, the form attribute references only form elements and not just any ids. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Sunday, 2 April 2006 12:38:30 UTC