Topic vs Domain Specialization

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

I've read through the original IBM DITA distribution writeups on topic 
and domain specialization and I'm having a hard time seeing a 
fundamental difference between the two forms of specialization.

I do understand that they represent different *degrees* of effort such 
that specializing a topic to a new topic type requires more thought and 
typing than does specializing p or ph to a domain-specific type. I also 
recognize that there are two clearly distinct specialization use cases 
(as discussed below).

But the practical result is the same in both cases: a new concrete 
document type with specialized element types.

In addition, the core mechanism for the specialization is the same and 
the constraints on specialization are the same.

Note that I'm purposely ignoring all the syntax tricks used in the 
current DITA DTD declaration sets--these may be useful practical syntax 
tricks but they cannot have any affect on the *semantics* of the 
resulting specialized document type. Therefore I consider them to be a 
distraction from the primary goal of understanding the basic semantics 
and rules of specialization.

What I see the DITA spec saying is that there are two basic 
specialization use cases:

- You don't need new topic types but you do need new "content" types 
(where by "content" I mean "the stuff you can put in the topic body" and 
by "topic" I mean "topic and its direct children")

- You do need new topic types, and as part of that you may or may not 
also need new content types

DITA also recognizes that a given set of domain-specific 
specicalizations may be useful in different contexts, so it is useful to 
modularize their declarations.

I agree with all of these observations.

DITA is also observing, correctly I think, that in many cases the only 
useful semantic difference between documents is at the content level 
where you need either specialized mentions (specializations of ph) that 
refer to instances of domain-specific things or you need specialized 
structures for containing structured data about domain-specific things 
(e.g., characteristics data for laser printers).

That is, some business-specific requirements can be met by specializing 
*only* at the content level and some can only be met by specializing at 
the topic level. This is a fact, so I'm not disagreeing with this 
distinction as a practical one and useful one.

However, I'm not seeing how this distinction does or should lead to two 
fundamentally different types of specialization *mechanism*. It may lead 
to different specialization *practice*, but the underlying mechanism 
should be the same, or at least have a common underlying base mechanism.

In particular, I'm curious as to why DITA needs the domain declaration 
and why the class value distinguishes topic-level specializations from 
domain-level specializations through the use of "+" or "-" as the 
leading character.

That is, I'm not seeing how the processing of a given element in terms 
of its specialization hierarchy would differ simply because it's a 
domain element or a topic element.

So what essential bit of understanding am I missing?

I'm also thinking that a lot of these issues of domain vs. topic 
specialization, specialization constraints, and domain modularization 
become a lot clearer and easier to work with when using XSD schemas, 
where you do have explicit declarative ways to define specialization 
constraints and to do specialization. I've done some experimental work 
along these lines but I'm not quite ready to share the results--I need 
to get some more experience and do some more thinking about the 
implications of the approach I've taken because I'm not 100% sure it's 
the best approach. I also need to develop generic examples of what I've 
so far done for a specific client.

I think that one possible issue here is that the limitations of DTD 
syntax have forced the original DITA developers to depend on syntax 
tricks and conventions when they really need formal, declarative ways to 
do things.

Cheers,

Eliot
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122

eliot@innodata-isogen.com
www.innodata-isogen.com