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/24/09 3:52 PM, "Tim Grantham" <tgrantham@timgrantham.com> wrote:

> Thank you for the publishing world specialization examples.
> You ones you mention -- article, sub-section, and so on -- are, as you say,
> container specializations rather than what I would call semantic
> specializations, since they are not intended to model or constrain the type
> of subject matter they contain. This is entirely understandable in the
> publishing realm, which must find commonalities not in subject matter, which
> changes very frequently, but in how that subject matter is packaged: as
> articles, as collections of articles, as sidebars, as bylines, and so on.
> In the BusDocs SC, we've been focusing on semantic specializations, since we
> believe these are the ones of most immediate value to business users, who
> are looking for commonalities in subject matter: value propositions,
> functional specifications, policies, and so on. As such, the semantics of
> the existing concept, task, and reference topic types can be applied more or
> less easily to business content.

It's not clear to that, for example, defining a "policy" topic type as a
specialization of concept, rather than as a specialization of topic, buys
you anything in terms of semantic description and it inherits structural
constraints that may not always be appropriate, depending on the use case.

That is, defining a topic type "policy" makes a semantic distinction that is
useful. The degree to which a given enterprise wants to make its policy
descriptions more or less formal (therefore their content rules more or less
constrained) is a local policy decision that should not be imposed by a
standard of the level of generality that anything produced by the TC or its
subcomittees should be, at least in their most general forms (one could
always define either associated constraint modules or more-specialized types
that express more severe policies that are likely to be commonly wanted).

Thus my caution about assuming that concept, in particular, the appropriate
base type for any topic type that is not clearly task or reference.

Or said another way: as semantic types "task" and "reference" are pretty
clear and of obvious utility, concept not as much, because it is, by its
nature it is "anything that isn't task or reference". It is of course
compelling in the context of technical documentation that wants to formally
reflect the task/concept/reference model.

Classifying content as "concept" outside the context of more or less formal
technical documentation where good tech com practice has been applied
doesn't really tell you anything predictive about the content beyond
"probably not reference or procedural stuff".



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]