Re: [dita] Errata for DITA 1.2 - filename convention for DTD constraintmodules.

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

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