[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Refinement of XSD Constraint Specifications
I presented a paper on RELAX NG and DITA at the Balisage conference and as part of that paper talked about the issues with XSD redefine and the problems it poses. Out of the discussion following my paper I learned that in fact the way we had been doing constraints was unnecessarily complicated in many cases. The challenge is the requirement for xs:redefine that every "particle" in the group being redefined be accounted for in the redefined group. Here "particle" means any group or element reference, distinct sequence or group wrapper, etc. This causes a problem when you want to omit something (which is usually what constraints are doing) because you can't simply redefine the group and leave out the things you don't want when the group is a sequence (the way you can with DTDs and RELAX NGs). Eric's solution to this was to use a pattern of intermediate groups, where each intermediate group is defined in such a way that you can just leave things out. However, what I learned was that the intended way to "leave things out" is actually to set the maxOccurs and minOccurs values to "0", which effectively makes the particle (group reference) disallowed but satisfies the particle correspondence requirement of xs:redefine. This approach avoids the issue I reported earlier with sequence content models not being inherently constrainable. With this approach, any content model can be constrained simply by copying it and changing the maxOccurs value to "0" (the minOccurs must already be zero or it wouldn't be valid to constrain it away). Using this approach, for example, the base taskbody content model can be rewritten to directly match the RELAX NG model: <xs:group name="taskbody.content"> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:group ref="context" minOccurs="0"/> <xs:group ref="prereq" minOccurs="0"/> <xs:group ref="section" minOccurs="0"/> </xs:choice> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="1"> <xs:group ref="steps"/> <xs:group ref="steps-unordered"/> <xs:group ref="steps-informal"/> </xs:choice> </xs:sequence> <xs:sequence> <xs:group ref="result" minOccurs="0"/> <xs:group ref="example" minOccurs="0" maxOccurs="unbounded"/> <xs:group ref="postreq" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:sequence> </xs:group> With this base the strict taskbody constraint can then be: <xs:group name="taskbody.content"> <xs:sequence> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:group ref="context" minOccurs="0"/> <xs:group ref="prereq" minOccurs="0"/> <xs:group ref="section" minOccurs="0" maxOccurs="0"/> </xs:choice> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="1"> <xs:group ref="steps"/> <xs:group ref="steps-unordered"/> <xs:group ref="steps-informal" maxOccurs="0" minOccurs="0"/> </xs:choice> </xs:sequence> <xs:sequence> <xs:group ref="result" minOccurs="0"/> <xs:group ref="example" minOccurs="0" maxOccurs="unbounded"/> <xs:group ref="postreq" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:sequence> </xs:sequence> </xs:group> Note the maxOccurs="0" on the reference to the section and steps-informal groups. This implements the constraint without the need for intermediate groups. Given this new way to do constraints, should we rework the current strict taskbody constraint to use the method shown here or should we maintain the DITA 1.2 intermediate group model? Changing the XSD definition would break any existing constraints applied to that model. However, the chance of those actually existing seems vanishingly small. In any case, I propose that we update the current XSD constraint topics to explicitly describe this method of defining constraints. The other TC-defined constraint, the machinery taskbody constraint, is still problematic because it's both integrating a domain and then constraining the content model of taskbody, so it may still require two levels of redefine. I'm working on that now. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]