OASIS Darwin Information Typing Architecture (DITA) TC

The text highlighted in red was modified as a result of the review. The content was reorganized; it previously was an unordered list, and then it is in a definition list. (I'd appreciate feedback about whether the latter improves usability.) Kris Constraint rules There are certain rules that apply to the design and implementation of constraints. @domains attribute contribution Each constraint that is integrated into a DITA document type MUST be declared in the @domains attribute for each structural type that is integrated into the document type. For DTDs, the contribution for the @domains attribute is specified in the constraint module file; for XSD and RELAX NG, the contribution to the @domains attribute is specified directly in the document type shell. Content model The content model for a constrained element must be at least as restrictive as the unconstrained content model for the element. The content model and attributes of an element can be constrained by only one constraint module. If two constraint modules exist that constrain the content model or attributes for a specific element, those two modules must be replaced with a new constraint module that reflects the aggregation of the two original constraint modules. Domain constraints When a domain module is integrated into a document type shell, the base domain element can be omitted from the domain extension group or parameter entity. In such a case, there is no separate constraint declaration, because the content model is configured directly in the document type shell. A domain module can be constrained by only one constraint module. This means that all restrictions for the extension elements that are defined in the domain must be contained within that one constraint module. Structural constrains Each constraint module may constrain elements from only one vocabulary module. For example, a single constraint module that constrains <refsyn> from reference.mod and constrains <context> from task.mod is not allowed. This rule maintains granularity of reuse at the module level. Constraint modules that restrict different elements from within the same vocabulary module can be combined with one another. Such combinations of constraints on a single vocabulary module have no meaningful order or precedence. -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype)

I prefer the dl layout. I also agree with the changes in red. On Sat, Jan 24, 2015 at 10:10 AM, Kristen James Eberlein < kris@eberleinconsulting.com > wrote: The text highlighted in red was modified as a result of the review. The content was reorganized; it previously was an unordered list, and then it is in a definition list. (I'd appreciate feedback about whether the latter improves usability.) Kris Constraint rules There are certain rules that apply to the design and implementation of constraints. @domains attribute contribution Each constraint that is integrated into a DITA document type MUST be declared in the @domains attribute for each structural type that is integrated into the document type. For DTDs, the contribution for the @domains attribute is specified in the constraint module file; for XSD and RELAX NG, the contribution to the @domains attribute is specified directly in the document type shell. Content model The content model for a constrained element must be at least as restrictive as the unconstrained content model for the element. The content model and attributes of an element can be constrained by only one constraint module. If two constraint modules exist that constrain the content model or attributes for a specific element, those two modules must be replaced with a new constraint module that reflects the aggregation of the two original constraint modules. Domain constraints When a domain module is integrated into a document type shell, the base domain element can be omitted from the domain extension group or parameter entity. In such a case, there is no separate constraint declaration, because the content model is configured directly in the document type shell. A domain module can be constrained by only one constraint module. This means that all restrictions for the extension elements that are defined in the domain must be contained within that one constraint module. Structural constrains Each constraint module may constrain elements from only one vocabulary module. For example, a single constraint module that constrains <refsyn> from reference.mod and constrains <context> from task.mod is not allowed. This rule maintains granularity of reuse at the module level. Constraint modules that restrict different elements from within the same vocabulary module can be combined with one another. Such combinations of constraints on a single vocabulary module have no meaningful order or precedence. -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290 ; kriseberlein (skype) --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Bob Thomas +1 720 201 8260 Skype: bob.thomas.colorado Instant messaging: Gmail chat ( bob.thomas@tagsmiths.com ) or Skype Time zone: Mountain (GMT-7)

Fix the spelling on structural constraints. I like the dl. Sent from my iPad JoAnn Hackos President Comtech Services Inc 710 Kipling Street Suite 400 Lakewood CO 80215 303-232-7586   CIDM will be hosting the Content Management Strategies/DITA North America 2015 conference in Chicago, Illinois  April 2 0-22. More information at: http://www.cm-strategies.com/2015/index.htm On Jan 24, 2015, at 12:14 PM, Bob Thomas < bob.thomas@tagsmiths.com > wrote: I prefer the dl layout. I also agree with the changes in red. On Sat, Jan 24, 2015 at 10:10 AM, Kristen James Eberlein < kris@eberleinconsulting.com > wrote: The text highlighted in red was modified as a result of the review. The content was reorganized; it previously was an unordered list, and then it is in a definition list. (I'd appreciate feedback about whether the latter improves usability.) Kris Constraint rules There are certain rules that apply to the design and implementation of constraints. @domains attribute contribution Each constraint that is integrated into a DITA document type MUST be declared in the @domains attribute for each structural type that is integrated into the document type. For DTDs, the contribution for the @domains attribute is specified in the constraint module file; for XSD and RELAX NG, the contribution to the @domains attribute is specified directly in the document type shell. Content model The content model for a constrained element must be at least as restrictive as the unconstrained content model for the element. The content model and attributes of an element can be constrained by only one constraint module. If two constraint modules exist that constrain the content model or attributes for a specific element, those two modules must be replaced with a new constraint module that reflects the aggregation of the two original constraint modules. Domain constraints When a domain module is integrated into a document type shell, the base domain element can be omitted from the domain extension group or parameter entity. In such a case, there is no separate constraint declaration, because the content model is configured directly in the document type shell. A domain module can be constrained by only one constraint module. This means that all restrictions for the extension elements that are defined in the domain must be contained within that one constraint module. Structural constrains Each constraint module may constrain elements from only one vocabulary module. For example, a single constraint module that constrains <refsyn> from reference.mod and constrains <context> from task.mod is not allowed. This rule maintains granularity of reuse at the module level. Constraint modules that restrict different elements from within the same vocabulary module can be combined with one another. Such combinations of constraints on a single vocabulary module have no meaningful order or precedence. -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290 ; kriseberlein (skype) --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Bob Thomas +1 720 201 8260 Skype: bob.thomas.colorado Instant messaging: Gmail chat ( bob.thomas@tagsmiths.com ) or Skype Time zone: Mountain (GMT-7)