These are some of the issues that we have been grappling with in the
BusDocs subcommittee.
/B
> -----Original Message-----
> From: Chris Nitchie [mailto:]
> 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" <> 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
>
>
