Co-occurrence constraints

Co-occurrence constraints (also: 'co-constraints') are rules which govern what kinds of markup (elements, attributes) can occur together (co-occur) in an XML document. Co-constraints as a topic are of interest for any schema language used to constrain XML documents; much of the discussion here is focused on the possibility of supporting co-constraints in W3C XML Schema.

Examples:

• There should be an 'a' attribute or a 'b' attribute on this element; at least one should appear, but not both.
• If an 'a' attribute appears, a 'b' attribute is optional, but 'b' should not appear unless 'a' does.
• If the value of the 'a' attribute is 'x', then the 'b' attribute is required, otherwise it's not allowed.
• The value of the 'minOccurs' attribute should be less than the value of the 'maxOccurs' attribute.
• If the value of the 'a' attribute is 'x', then the content model (or: the type) of the element should be this ... and if the value of 'a' is 'y', the content model (type) should be this ...

See Co-constraint Use Cases.

Many constraints of this kind are straightforward when applied to elements: it's easy to write a content model in DTD or XSD notation that allows an 'a' child or a 'b' child but not both, and so on. In practice, the term is usually used to denote constraints that are not handled conveniently or at all by content models in DTDs or XSD.

Several distinct approaches to defining co-constraints may be distinguished (these approaches should be described either here or on other pages):

• grammaticalization of attributes and type assignments, in the style of RelaxNG
• CheckClauses: predicate expressions associated either with the document node or with individual elements or attributes (and declared either at schema level, in individual element or attribute declarations, or in individual type definitions)
• ConditionalTypeAssignment (as represented by SchemaPath): making the determination of the type against which an element (or attribute) will be validated depend on conditions tested in the context of the individual element/attribute instance. Also, see the ConditionalTypeAssignment page for discussion of the relationship between the Atom use case [1] and xsi:type.
• ConditionalTypes: types which themselves contain conditions and choices.