Errata for DITA 1.2 - filename convention for DTD constraint modules.

[Eric Sirois <esirois@ca.ibm.com>]

Hello,

Eliot and I have been working with a
user on dita-users regarding his need to restrict the choice of elements
from the programming domain.  

We have both come to the same conclusion.
 Whenever the process permits, we should update the spec so that it
lists that .mod and  .ent  as appropriate extension in the filename
convention topic for the constraint mechanism. The spec (section
2.1.1.4 ) [1] only lists a .mod
extension for a constraint module.

The issue came to light while working
on a solution where the user only wanted to limit the existing elements
that are available in the programming domain.  For instance:

Existing definition - programmingDomain.ent
<!ENTITY
% pr-d-ph      
  "codeph
| 
   synph
  "
>
<!ENTITY
% pr-d-pre     
  "codeblock
|
  synblk
  "
>
...

Constrained domain - myProgDomainConstraint.ent
<!ENTITY
% pr-d-ph      
  "codeph"
>
<!ENTITY
% pr-d-pre     
  "codeblock"
>

...

Requiring the user to create a .mod
file in this case is inappropriate. Since it would break the convention
of defining these types of parameter entities for a domain in a .mod file.



Kind regards,
Eric

[1] - http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/fileext.html#fileext

---

Eric A. Sirois
Staff Software Developer 
DB2 Universal Database - Information Development
DITA XML Schema Architect and DITA Open Toolkit Developer
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Phone:(905) 413-2841
Blue
Pages (Internal)

"Transparency and accessibility requirements dictate that public information
and government 
transactions avoid depending on technologies that imply or impose a specific
product or 
platform on businesses or citizens" - EU on XML-based office document
formats.