Hi Eliot, In domains and/or topic specialization the domains attribute contribution is defined in the .ent. For constraints, I would rather see the definition of the domains attribute contribution in a .mod file as the exception versus the norm. I would propose the following based one the following scenarios: 1) Restriction of choice elements in a domain. - domains attribute contribution is defined in a .ent file. 2) Restriction of content models - domains attribute contribution is defined in a .mod file. 3) (1) and (2) for a constraint - domains attribute contribution is defined in a .ent file. This allows us to remain consistent with the rest of the spec when dealing with constraints. That would mean that the cases like strictTaskbodyConstraint.mod is still valid and in the case listed below the domains attribute contribution is defined in the .ent. To summarize, a domains attribute contribution must be defined in a .mod file if and only if a .ent file does not exist for a particular constraint. Does that make sense? Kind regards, Eric 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. From: Eliot Kimber <
ekimber@reallysi.com> To: Eric Sirois/Toronto/IBM@IBMCA, dita <
dita@lists.oasis-open.org> Date: 01/18/2011 03:14 PM Subject: Re: [dita] Errata for DITA 1.2 - filename convention for DTD constraint modules. I think the .mod file is still required because you have to declare the @domains attribute contribution for the domain and the spec already says that even if all you're doing is omitting things through the domain configuration entities in the shell, you still need a .mod file in order to declare the constraint. Cheers, E. On 1/18/11 12:21 PM, "Eric Sirois" <
esirois@ca.ibm.com> wrote: > > 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 > <
http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/fileext.html#fileext > > ) [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 > <
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 < mailto:
esirois@ca.ibm.com > > Phone:(905) 413-2841 > Blue Pages > <
http://bluepages.ibm.com/cgi-bin/bluepages.pl?searchcnum=009764649&directory= > ALL> (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. -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368
www.reallysi.com www.rsuitecms.com --------------------------------------------------------------------- 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