OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]