[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [opendocument-users] RE: office-comment text:id vs xml:id (ODF 1.2CD01)
> 4. I don't think this will help us with xml:id and with the problems of > not knowing what the referential integrity conditions of ODF are because > we don't know what the references are under the existing schemas. But > namespace versioning, as it were, might help us when we see what hole it > is we are digging out of. I suppose that is another way to come at the > transition issue. (I'm still thinking that will be a 2.0-level > disruption.) With xml:id (and IDs in general) the problem is that there are three different systems at work. The first is IDs as used by linking applications: they typically make a list (index) of name/locator pairs to allow fast unique keyed access of elements. The second is IDs as used by traditional validators (DTDs, RELAX NG, etc): they work by checking for duplicates, so that a document reaching the application won't have duplicates (and therefore ambiguity) to cope with. The third is type assignment, such as XSD and object APIs: the element object gets a property. The trouble with the type assignment approach is that in XML Schemas (XSD) datatypes an ID (xs:ID) does not have any notion of uniqueness. See http://www.w3.org/TR/xmlschema-2/#ID This is because the primitive XSD types are atomic: they are not checked with any reference to other elements. (In XSD, the uniqueness checking happens during validation using the structures specification, see http://www.w3.org/TR/xmlschema-1/#sic-id and the ID/IDREF table is part of the Post Schema Validation Infoset (PSVI). Uniqueness is a function of schema processing, not intrinsic to the datatype xs:ID.) In XSD it was recognized that the ID/IDREF mechanism was a too blunt instrument: the issue of an element having two IDs (e.g., one for one application, another for another. Or when transitioning from one attribute name to another.) So it introduced a key/keyref mechanism (which is not based on types but names.) In the OASIS/ISO RELAX NG family (ISO DSDL), there may be a more direct equivalent of key/keyref developed in the future, but ISO Schematron can already handle these kinds of constraints. I think it is a mistake to get too hung up on expecting some magic from using xs:ID rather than xs:NCName (the type from which xs:ID is derived.) Indeed, there is *no* difference in the lexical or value spaces of xs:ID from xs:NCName. When real-life (i.e. document evolution) means that you have to go beyond what ID provides, then you really need to move either to Schematron or XSD key/keyref. For example, consider these possibilities: * An element can have both an @name attribute and an @id attribute but both must have the same value and be unique: this is what (X)HTML did. * An element can have both a @name attribute and an @xml:id attribute but both must have different unique values. * An element can have both a @name attribute and an @xml:id attribute but the @name values must be unique and the @xml:id values must be unique: they form different key/keyref systems (this is what XSD supports). HTML is a good example to think about. They used @name at first, then moved over to @id, but still allowing @name. Very sensible. The point is that RELAX NG, XML Schemas and DTDs all only provide very simple ID systems. It should not be a surprise to anyone that they run out of steam very early. They are not designed to be anything other than 80/20 solutions. Very simple Schematron schemas can allow declaration and validation of almost any kind of complex ID/IDREF constraints: a 99/1 solution. So here are some approaches that the ODF WG could take is to say that an element with both an old ID attribute and an xml:id should have the same value in both, and: 1) Use xs:NCName for all IDs. Then make a Schematron schema for the uniqueness constraints. 2) Use xs:ID for all existing IDs, and xs:NCName for all new attributes such as xml:ID. Then make a Schematron schema for the uniqueness constraints. 3) Use an xs:ID for all xml:IDs, and xs:NCName for all old ids. Then make a Schematron schema for the uniqueness constraints. 4) Use an xs:ID for all xml:IDs and for existing IDs on other elements, and xs:NCName for superceded ids. Then make a Schematron schema for the uniqueness constraints. I don't know that any of these choices is particularly better than another. Probably people would be most comfortable with 4), because it provides the best declarations for a databinding tool might use. Cheers Rick Jelliffe
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]