[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Vertical Industry Vocabulary in DITA 1.3
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]