[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Errata for DITA 1.2 - filename convention for DTDconstraint modules.
Yes, I think that is the right approach. Cheers, E. On 1/19/11 9:30 AM, "Eric Sirois" <esirois@ca.ibm.com> wrote: > > 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 <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. > > > 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 >> <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> >> <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 >> <mailto:esirois@ca.ibm.com> > >> Phone:(905) 413-2841 >> Blue Pages >> <http://bluepages.ibm.com/cgi-bin/bluepages.pl?searchcnum=009764649&directory >> = >> <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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]