OASIS Darwin Information Typing Architecture (DITA) TC

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:







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

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