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: Re: [dita] C/T/R Not Universal (was problem with packaging ofglossaries)

On 8/25/09 3:32 PM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:

> Eliot, this line of argument (the exchange with Tim below), while
> intended to support deriving types like policy directly from <topic>,
> actually limns pretty well the argument for simplified base topic types
> from which the current TD-specialized C/T/R would then be specialized, a
> strategy that Michael also was endorsing today (in parallel to or rather
> as an alternative to a constraints strategy).

I certainly agree with this approach in general: I've felt for a while that
the first level of specialized topic types are too specific and that some
number of intervening levels of more-general types, both for topic types and
for content elements, would be valuable. However, that is probably not
practical to do in a 1.x time frame for backward compatibility (although I
would be pleased to be proved wrong in that assumption).

Another potential issue, which I haven't seen addressed, is the distinction
between the information type taxonomy, e.g., concept, task, reference, and a
specific specialization hierarchy.

At the moment, those two must by necessity be the same because the only
mechanism DITA 1.x provides for expressing information type is the topic
type itself.

However, the notion of "concept" as an information type is clearly distinct
from the element type "concept" as used in a particular specialization

We see that with the new task model, where we've recognized that it's
important to know that a topic is a task, regardless of what its specific
content constraints are (otherwise we would have just defined two task
types, "task 1" and "task 2" and been done with it). Because we have no way
to express information types other than with element type names, we had to
interpose a more generic task from which a more-specialized task could be
constructed, either by specialization or by constraint application.

To the degree that information types have value as descriptive metadata
(e.g., "find all concepts in my information base"), I think it follows that
it would be useful to be able to classify topics as "concept" independent of
their specific class hierarchy, meaning that I should, in theory, be able to
have my own specialization hierarchy, rooted at topic, that has a formal
binding of topic types, of whatever name, to the information type "concept".

[Of course, that immediately raises the engineering question of whether such
a mechanism would be worth the extra complexity--to add such a mechanism we
would have to be certain that the benefit outweighs the cost--it very well
might not.]

Or said another way, there are at least two important taxonomies at play in
DITA, which serve different and important purposes:

1. The information type taxonomy, which classifies topics in terms of an
information type taxonomy.

2. The topic type taxonomy, which defines structural constraints in order to
enable interchange and interoperation (e.g., conref, common processing,

Both are very important, and to date, the second has clearly been the more
important because it is essential to making DITA what it is (an XML
application that enables blind interchange of modular information).

But with this discussion of business documents vs. tech docs vs. publishing
documents we're seeing that the first taxonomy, that is pure information
typing divorced from issues of content interoperation, is also important and
becoming more important as there is more diversity in content and in use

I'm not proposing any changes, just making the observation that there are
these two dimensions of DITA's architecture and implementation and we need
to be sure we're clear which aspect we're focusing on when discussing topic
types and typing in general.



Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com> 

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