OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]