MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Topic vs Domain Specialization
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]