Re: [dita] Comments on Glossary elements section

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

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 <p>? 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