Robert D Anderson wrote:
> Do you (or anybody else) have any better wording for the glossentry
> element, or for the common text that appears with elements like ? For
> glossary, I could change the text to something like this:
> In the OASIS Composite document type, the glossentry element can be
> contained by other topic types (topic, concept, task, reference), and by
> the dita element.
> In the OASIS glossentry topic type, the glossentry element cannot be
> contained by any other element.
> Like other topic types, this model may differ when the glossary module is
> used in new document types.
I still don't see why there needs to be a difference--Michael's response
didn't do anything to help me understand why there needs to be a
difference and why there needs to be a *shared* info-types parameter
entity (given that there are already type-specific parameter entities
for constraining the allowed nesting of topics).
This whole problem would go away if we had consistent out-of-the-box
content models that didn't vary based on whether or not you're using
the ditabase declaration set or a more specialized declaration set *as
delivered*. [And I just realized that "ditabase" is a very poor name for
this declaration set--"ditaall" would be more accurate, I think.]
I don't think we need to say anything about the implications if you're
using a locally-defined document type--by definition all bets are off in
that case. We only need to document what the DITA *standard* says.
What I'm questioning is the need for a difference--it just doesn't make
any sense to me: if having a constraint on nested topics is sensible for
reference topics when authored using one set of declarations it must
always be sensible *or it shouldn't be there at all*. Today the standard
says "it is wrong to nest anything other than reference topics within
reference topics, except when it isn't".
That is, either the looser rules defined in the ditabase declarations
should be *the* rules defined in the standard or the tighter rules
should be--we shouldn't allow both. And since this is a generic standard
intended to be specialized we should probably use the looser rules and
let people add constraints as they need or want to.
As it is there's some ambiguity about whether or not it's even legal to
allow, for example, task w/in concept when you are using the concept.dtd
(or concept.xsd) as your specialization base given that the spec clearly
says you can't relax constraints.
It just seems unnecessarily confusing to me--the fact that we even have
to have this language certainly points to that.
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198
ekimber@innodata-isogen.com
www.innodata-isogen.com