RE: [dita] Vertical Industry Vocabulary in DITA 1.3

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

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