Re: [dita] Organization of the DITA Specification

[Eliot Kimber <ekimber@reallysi.com>]

Robert D Anderson wrote:
> Hi - I intended to send this out last Friday, but am just now getting to it
> - so it will sound a bit rushed.
> 
> The TC needs to put a small amount of thought into how the Specifications,
> including DTDs and Schemas, will be distributed with DITA 1.2.
> 
> There are now a couple of industry specific packages, with more to come in
> the future. Should these be bundled with the core? If in separate packages,
> should they include pre-requisite portions of the core, or must users
> download more than one package? What exactly is the core?
> 
> For example - how should one be able to access the machine industry
> specializations? It uses the task specialization, which (so far) is one of
> the core information types. So, would a Machine Industry bundle also
> include the task DTD and Schema modules, or the task specification?
> 
> Is there still a reason to have one large bundle with all of the DITA
> specifications in a single zip? I wonder if - in the future - it will be
> useful for a single user or implementer to grab every industry bundle at
> once.

I think that application-specific specializations, including bookmap and 
all industry-specific specializations should be packaged separate from 
the base DITA spec and working declarations. That is, they are, 
fundamentally, no different from any other user-defined specialization 
from a packaging standpoint.

That is, when one publishes a Java library you don't, by default, 
package it with Java, you just state the requirement with the reasonable 
assumption that most interested parties will already have the prereqs in 
place.  I think the same should be true for DITA.

This also makes it clearer what is core (topic, task, concept, 
reference) and what is standard but optional.

One potential problem with including the declarations in specialization 
packages is keeping all the packages in sync when new releases of the 
base packages are made (e.g., to fix bugs).

There is already confusion among users (and some implementors) as to 
what is and isn't required.

Cheers,

Eliot

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com