Re: [dita] While is info-types The Way It Is?

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

Michael Priestley wrote:
> 
> Re:
>  >What is the justification for having this shared parameter entity name
>  >(info-types) and why can't we define topic-specific parameter entities
>  >that allow us to have a single conherent set of declarations that
>  >encompasses all of the topic element types?
> 
> The idea is to provide control over how a particular doctype allows 
> nesting of different topic types:

> - If you just want a general bucket that allows any type as root and any 
> type nesting, you can use <dita> as a containing element, and list all 
> the valid structural types in the info-types entity.
> - If you want specific control (like concept only concepts, or concept 
> and task can nest reference but not vice versa) then you can set the 
> type-specific entities (like concept-info-types).

But that doesn't answer my question about why you need *one* parameter 
entity that leads to this syntactic conflict. Why not just have five, 
one for each DITA-defined topic type? It's not like the convenience 
provided is so overwhelming that without it people would be unable to 
manage the declarations.

> There is every possibility for a dozen different doctypes all using 
> <concept> as the root, and all allowing different nesting rules (as well 
> as combinations of included domains).

So what? That's not the point of my question: the point of my question 
is why are the declarations *as provided* defined in such a way that it 
is impossible to have what would otherwise be easy and natural: a single 
set of declarations that provide all the DITA-defined topic elements.

That is, there's no reason that every unspecialized DITA topic document 
couldn't have *exactly the same external identifier* regardless of what 
it's root element type is. The *only* reason is because of the use of 
the shared info-types parameter entity.

> Right now we don't have a meaningful way to communicate the nesting 
> rules to non-doctype-aware processes, the way we do with domain 
> inclusion. Since the main focus in DITA is on the topic, and nesting 
> rules are at a higher level, I don't think it's a huge problem, but it 
> is something we should probably look at for 1.2.

This can only be an authoring issue, right? Any generic DITA processor 
has to already handle the case of any topic type within any other topic 
type (since that's what the ditabase declarations allow) so why would 
knowing what the local constraints are matter to them at all?

 From an authoring standpoint, anybody doing non-schema-aware authoring 
is already in a world of pain we can't help them with so it's not worth 
worrying about.

If you're building a processor specifically for your locally-specialized 
DITA document type then you know what the nesting rules are (because 
it's your document type and you can just look at the declarations to see 
what the rules are) and even there the only reason to care would be to 
validate violations of the rules, which could only happen if somebody 
were violating the schema while creating documents....

If it's a question of what's allowed to be done via maps, that's another 
issue entirely and I don't think that defining nesting constraints on 
topic elements would be the solution there anyway. Rather it would 
probably make sense to allow topicref to declare what its reference type 
constraints are, which would then let you use specialized topicref 
elements to control what kinds of topics could be referenced from which 
contexts within a map.

Cheers,

E.
-- 
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