RE: [dita] Organization of Tagname Parameter Entities in DTD Modules

[Robert D Anderson <robander@us.ibm.com>]

I think I'd also prefer to hold it to 1.3. I know I tried to do something
of the kind earlier in the process, to make constraint definitions easier,
but ran in to trouble with domains. Moving the definition of some entities
to the ENT files meant that they were defined ahead of the domain section,
meaning that you couldn't extend the elements by re-defining them (first
definition in the ENT file won). At least, that's what I think happened.

I'm not sure that this is the same thing, but it sounds similar enough that
I'd really rather hold off until we have more time to test it. Also - I'm
not sure I entirely understand the issue - which makes me vaguely wonder if
it's not already possible to do it today (that is, the only place I've seen
any trouble from the location of entity definitions is with constraints).

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

"Grosso, Paul" <pgrosso@ptc.com> wrote on 07/22/2009 10:38:31 AM:

> "Grosso, Paul" <pgrosso@ptc.com>
> 07/22/2009 10:38 AM
>
> To
>
> "dita" <dita@lists.oasis-open.org>
>
> cc
>
> Subject
>
> RE: [dita] Organization of Tagname Parameter Entities in DTD Modules
>
> This sounds like a reasonable change to make in 1.3.  I'd really
> rather we didn't keep doing major reorganization to the 1.2 files
> at this time.
>
> paul
>
> > -----Original Message-----
> > From: Eliot Kimber [mailto:ekimber@reallysi.com]
> > Sent: Wednesday, 2009 July 22 9:31
> > To: dita
> > Subject: [dita] Organization of Tagname Parameter Entities in DTD
> Modules
> >
> > Currently, the DTD module pattern requires declaration of parameter
> entities
> > for each element type defined in a module for later use in content
> models.
> > These parameter entities are in the .mod file.
> >
> > However, with the advent of the ability in DITA 1.2 to do per-element
> > content model overrides, I think these entities should be in the .ent
> files,
> > so that they are available to content model overrides specified in
> shell
> > DTDs.
> >
> > For example, if I have shell "myconcept.dtd" and I want to extend the
> > content model of title to allow a new phrase type (e.g.,
> "my-title-phrase"),
> > without this change I have to declare the entities for each of the
> content
> > model tokens I'm retaining from the base content model, since they
> otherwise
> > occur *after* the shell-defined content model override entity is
> declared.
> >
> > I don't remember any discussion of this in the past, but I also
> haven't been
> > necessarily paying close attention.
> >
> > Is there any reason not to make this change?
>
>
>
> ---------------------------------------------------------------------
> 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
>