RE: [dita] C/T/R Not Universal (was problem with packaging of glossaries)

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

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). 

> 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.

The aim of simplification is to remove structural constraints that are
not appropriate across the range of business document types. 

Technical documentation is a type of business document, one type among
the many, and there are largely unexplored benefits of sharing content
into and out of technical documentation and among the various other
types of business documents. Product specification content should flow
into product user content, training content, sales support content,
customer support content, and all the vice versas. RFPs, proposals,
business cases, even policy documents and the like (certainly as those
are relevant to content in the other types). These are (almost?) always
siloed today, as they have been "forever". Cisco (and I assume this is
true of other companies) creates and publishes trade books and magazines
that could benefit from easier content sharing with these other classes
of documentation. 

The question is whether e.g. a policy is a type of concept. The
companion question is concerns the benefit for packaging and user
comprehension if we treat concept as the more general type from which
the TC-specialized concept and policy (among others) are derived. It is
important to limit the welter of types that would otherwise grow up as
immediate descendants of <topic>. I hear this as Michael's strong
concern as architect, and I could not agree more strongly.

On the Busdocs team we've been looking at a systemic relationship of
topic types that will provide a rational basis for expanding the set of
types in a rational and controlled way. Not to jump the gun or steal
anyone's thunder, I think you'll like it when it's ready to be exposed
to the full TC as part of our proposal.

	/Bruce

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Monday, August 24, 2009 5:31 PM
> To: tgrantham@timgrantham.com; dita
> Cc: Bruce Nevin (bnevin); 'Michael Boses'; 'Michael 
> Priestley'; 'JoAnn Hackos'; rockley@rockley.com
> Subject: Re: [dita] C/T/R Not Universal (was problem with 
> packaging of glossaries)
> 
> 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".
> 
> Cheers,
> 
> E.
> 
> 
> ----
> 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> 
> 
>