Re: [dita] Vertical Industry Vocabulary in DITA 1.3

[Eliot Kimber <ekimber@reallysi.com>]

The way I've been thinking about it in the context of DITA for Publishers
is:

1. If what I need is a specialization of existing element, then it's part of
the D4P vocabulary and needs no additional stuff from core DITA vocabulary.

2. If what I need is really an extension to base vocabulary then propose the
extension. A good example would be my 1.3 proposal to add markup for
strike-through to the highlight domain--that seems like an obvious missing
feature for which a one-element domain would be bit silly as a local
extension.

3. If what I need is new architectural feature, propose the feature. An
example would be my proposal for an extension to keyref to allow specifying
the root map that defines the key space the key reference should be resolved
in.

The fuzzy boundary here is where items in (1) may arguably have general
utility. That's a judgment call that the TC has to make but I think in most
cases it will be easy to decide. In general, if an element has a generic
semantic it should probably be in the base vocabulary, otherwise it
shouldn't. DITA already does a pretty good job of covering the base
structures any document would need (topic, paragraph, list, figure, table,
mentions, arbitrary formatting, generic metadata, links) so I would expect
it to be rare to find new base-level element types except for the odd case
like strike-through that simply reflects a lack of requirement because of
the original relatively narrow use community of DITA pre OASIS.

So I would expect that 80-90% of new things that people require fall into
category (1).

Cheers,

E.

On 2/23/11 8:16 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:

> These are some of the issues that we have been grappling with in the
> BusDocs subcommittee.
> 
>         /B
> 
>> -----Original Message-----
>> From: Chris Nitchie [mailto:cnitchie@ptc.com]
>> Sent: Wednesday, February 23, 2011 8:02 AM
>> To: Eliot Kimber; DITA TC
>> Subject: Re: [dita] Vertical Industry Vocabulary in DITA 1.3
>> 
>> I agree entirely, and I'd even take it one step further and
>> say that we should either move the technical content doctypes
>> out of the core spec or start referring to them explicitly as
>> a 'sample doctype family implementation' or somesuch.
>> 
>> Chris
>> 
>> 
>> On 2/23/11 7:34 AM, "Eliot Kimber" <ekimber@reallysi.com> wrote:
>> 
>>> [This is a reaction to Jontan Lundin's responsse to the
>> Refinements to
>>> DITAVAL for Flagging: not to the substance of his post but to the
>>> implications of the questions and requests that he's making. I'm
>>> starting a new thread because this is a meta-comment, not a direct
>>> response to Jontan.]
>>> 
>>> I can see value in having one or more
>> machine-industry-specific @props
>>> specialization modules and declaring them is almost trivially easy.
>>> That could be done unilaterally at any time without a need
>> to add them
>>> to the base DITA spec.
>>> 
>>> That is, the Machine Industry SC, or any other
>> community-specific SC
>>> or anyone else, can declare and provide such modules *at any time*
>>> without the need for the TC to do anything more than
>> approve the work
>>> product as required by OASIS rules.
>>> 
>>> I have been hopeful that the DITA for Publishers project
>> would serve
>>> as an example of an industry meeting its own requirements through
>>> development of its own specializations separate from the TC, but I
>>> don't think its reached a level of maturity sufficient to generate
>>> enough visibility to make that point. But nevertheless, I
>> think DITA
>>> for Publishers is a good example of just that: an industry-specific
>>> group defining its own vocabulary without the need to work
>> through the
>>> TC or even through OASIS. Once D4P is more than just me I will look
>>> for the appropriate standards venue to take it over, and
>> that might be
>>> OASIS or it might be IDEAlliance or it might be SPECTRE, I
>> don't know yet. The point is that it doesn't have to be OASIS.
>>> 
>>> But the larger issue is: I think this is an example of an
>> area where
>>> vertical requirements should start to be satisfied through separate
>>> specifications and not baked into the core DITA vocabulary. Machine
>>> Industry is just one example. Publishing is another, Learning and
>>> Training yet another.
>>> 
>>> The original selection attributes are really legacy that, if @props
>>> had been in DITA 1.0, would (A) have been specializations of @props
>>> (and could be today if we cared) (B) could have been in a
>>> tech-doc-specific module, rather than being mandatory. We could
>>> back-define those attributes as @props specializations in
>> DITA 1.3 if
>>> we wanted to since that would change any functional aspects
>> of those
>>> attributes or processors that recognize them today based merely on
>>> their names. That would make the DITA vocabulary cleaner and more
>>> consistent, leaving only @rev as a special case because of its
>>> "flagging only" semantic (and maybe we need a base
>> attribute from which @rev could be specialized--hmmm).
>>> 
>>> One of the reasons that I harp on the need for all
>> production users of
>>> DITA to create local shell document types is that I know they will
>>> need to specialize from @props sooner rather than later,
>> because the
>>> base set of selection attributes is clearly not sufficient for most
>>> users of DITA. The TC and the Adoption TC need to make that
>> point more clearly.
>>> 
>>> For DITA 1.3, rather than continuing to add more and more
>> stuff to the
>>> base vocabulary, I would like us to start moving vertical
>> vocabulary
>>> into separate specifications, reserving the base vocabulary
>> for things
>>> that are either of universal utility or essential to the
>> architecture
>>> as a whole. We should not be adding any new attributes or elements
>>> that are specific to any particular industry or use domain.
>>> 
>>> This goes also to the "DITA is too complex" issue: we have to start
>>> making a much clearer distinction between "DITA" as a core
>>> architecture and base vocabulary, and "applications of DITA" that
>>> satisfy specific requirements of specific communities. We
>> need to do two things in this regard:
>>> 
>>> 1. Produce separate specifications out of the TC for
>> industry-specific
>>> vocabulary we've already agreed to do (Machine Industry,
>> Learning and
>>> Training, BusDocs, etc.) 2. Help the community at large understand
>>> that they don't require the TC to create their own
>> community-specific
>>> standard DITA applications.
>>> 
>>> Essentially, we need to wean the community off their
>> dependence on us
>>> for satisfying their local requirements (where by "local" I include
>>> large communities like "Publishers" or "Pharma"). The way
>> we've been
>>> doing things is unsustainable and we have to stop.
>>> 
>>> That is, we need to start using DITA's specialization facility for
>>> what it
>>> enables: letting communities of interest unilaterally satisfy their
>>> own markup requirements.
>>> 
>>> Our focus should be entirely on architectural aspects that enable
>>> satisfaction of requirements that cannot be met through
>>> specialization, that is things that require new generic
>> facilities or
>>> extension of base types in some way.
>>> 
>>> Cheers,
>>> 
>>> Eliot
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS
>> TC that generates this mail.  Follow this link to all your
>> TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
>> oups.php
>> 
>> 

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com