OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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?



W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]