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

[Michael Priestley <mpriestl@ca.ibm.com>]

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

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

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.

In terms of file vs. document, and composite/compound
document: agreed we need to clear up the terminology.

In terms of clear definition of <dita>: there's
a mention of it in the terminology section, under "document type"
shell" but I think you're right it needs more substantial explanation.


Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

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

01/22/2007 10:40 PM

To	<dita@lists.oasis-open.org>
cc
Subject	[dita] While is info-types The Way It Is?

Per my prior comment on the "dita" element
and the ditabase document 
type, it's always bothered me that the topic types are declared and 
organized as separate document types--there's no reason for it except 
for the way the info-types parameter entity is used.

This must be true because the ditabase declaration set allows you to mix
all the DITA-defined topic types. Were it not for the re-use of of 
info-types parameter entity in the content models of all the topic types
you could have one coherent set of declarations with *exactly one* 
URI/public ID and everything would just work.

That is, the current declaratoin set organization seems to be based on
the mistaken idea that every declaration set defines exactly one allowed
root element type, which of course is not the case.

That is, using the ditabase declaration set, I can have both of these 
documents and they are both perfectly valid:

<!DOCTYPE dita SYSTEM "database.dtd">
<dita><concept><title>A Concept</title></concept></dita>

<!DOCTYPE concept SYSTEM "database.dtd">
<concept><title>A Concept</title></concept>

The only difference is the root element type.

I don't have a problem with organizing the declarations for the 
different topic types into separate declaration set modules--that makes
perfect sense, especially when you want to create a specialized set of
declarations that only reflects some of the base topic types.

What I'm objecting to is that the info-types parameter entity *requires*
that you must have *both* an all-encompassing declaration set that 
provides all the topic types *as well as* topic-specific document types
that must have distinct external identifiers, which adds avoidable 
complication (because all these external identifiers have to be mapped
in catalogs or otherwise managed).

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?

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