Open content, sort of

From W3C Wiki
Jump to: navigation, search

Open content, sort of (a co-constraint use case)

Use co-constraints to require the presence (in any order) of a specified set of known/expected children, while allowing other child elements to occur as well.

source: [1]


Other use cases: Co-constraint Use Cases

Description

   Is there any possibility to define (in an xml schema) a type,
   containing only simple types, of which some are required, and all
   the others unknown.
   In other words: define a type in which i know what elements are
   supposed to be present, but do not know which "might" be present.
   eg: the following type must contain 'a', 'b', and 'c', but might
   also contain some other elements. It is also important to state
   that the order af appearance is of no siginificance.


        <letters>
            <a/>
            <hollat/>
            <c/>
            <club/>
            <b/>
            <smit/>
            <pliq/>
        </letters>


Restatement from a subsequent message in thread [2]:

   I want to validate that a certain parent element contains some mandatory
   fields. I do not however care what else it might contain.
   Additionally, I do not care what is the order of all the elements in the
   parent. (some "garbage" elements can occur mixed between mandatory elements)
   I do not even know the quantity of child elements I expect to occur.

Analysis

(Add your analysis here; see your name in pixels!)

MSM

This use case could be handled without co-occurrence constraints by relaxing some rules in XSD 1.0:

  • Ease the constraint on all-groups to allow maxOccurs to exceed 1 (already agreed in principle).
  • Ease the Unique Particle Attribution Constraint to allow competition between element declarations and wildcards (also already agreed in principle).
  • Allow wildcards to occur within all groups (this is currently not allowed).

With those changes, a wildcard could be used to allow the all-group to contain elements other than a, b, c. To match the behavior shown by the original poster, interleave semantics for the all-group are preferable to SGML semantics.


 <xsd:complexType name="open_content_sort_of">
  <!--* N.B. this formulation is not legal in XML Schema 1.0, or
      * in the current draft of XSD 1.1.   Don't try this at home.
      *-->
  <xsd:all>
   <xsd:element ref="a"/>
   <xsd:element ref="b"/>
   <xsd:element ref="c"/>
   <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:all>
 </xsd:complexType>


Allowing open content in the direct way (by an open-content flag of some kind) would be even more direct. The declaration then becomes


 <xsd:complexType name="open_content_really" open="true">
  <xsd:all>
   <xsd:element ref="a"/>
   <xsd:element ref="b"/>
   <xsd:element ref="c"/>
  </xsd:all>
 </xsd:complexType>


where open is taken to mean that any sequence of children is valid if by deleting zero or more items from it you can produce a sequence which strictly matches the content model. ('Strict' matching is what we have now and what we are familiar with from DTDs.) Cf. the "validate twice with surgery" proposal, which achieves the same end in certain restricted cases (when all the children are global, and none of the extra children is declared, and ... and ...)

A third way to support the use case would be to introduce an interleave operator with the usual semantics: L1 interleave L2 is the set of strings which are interleavings of two strings S1 in L1 and S2 in L2 -- i.e. if you put dots under some subset of the symbols in the string, and project first the sequence formed by the dotted items, in order, and then the sequence formed by the undotted items, in order, those two sequences are members of L1 and L2 respectively.

Under the circumstances, I'm inclined to say this is an important use case to support, but that co-occurrence constraints are not the best way to do it. (On the other hand, any co-occurrence constraint interesting enough to be adopted will support this use case, so it's not going to be possible to prevent people from doing this with co-occurrence constraints.)

Possible solutions

Relax NG

Schematron

Check clause

SchemaPath

Conditional Type