Cart
[Home] [By Thread] [By Date] [Recent Entries]
> My current thinking is that the ID/IDREF approach to uniqueness > constraints doesn't really scale. For example, there's no way I can see > to make it handle multipart keys. ID isn't purely a datatype in the same > way that NMTOKEN is: making an attribute have type ID has side-effects > on the validity of other attributes that making an attribute have type > NMTOKEN does not. I think it's better therefore to move to a completely > different approach to handling uniquessnes and cross-reference > constraints, more along the lines of the identity constraints in W3C's > XML Schemas. I second you! > Another interesting issue with ID and with type-assigment is how it > interacts with intersection (the "concur" operator in TREX). What do I > do with something like this Since your example uses <concur>, every attribute "a" must be considered as ID and there are no other possible interpretation. Things get tricky if you change <concur> to <choice>. We can't decide any more whether "a" attribute is ID. And I guess that what you intended. > <choice> > <element name="e"> > <attribute name="a"> > <data type="xsd:ID"/> > </attribute> > </element> > <element> > <anyName/> > <zeroOrMore> > <attribute> > <anyName/> > </attribute> > </zeroOrMore> > </element> > </choice> regards, ---------------------- K.Kawaguchi E-Mail: k-kawa@b...
|
