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:
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.
