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: Vertical Industry Vocabulary in DITA 1.3


Eliot,

Thank you for expressing this opinion, which exactly matches mine:

". . . vertical requirements should start to be satisfied through separate
specifications and not baked into the core DITA vocabulary"

Bravo!

- Bryan Schnabel

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Wednesday, February 23, 2011 4:34 AM
To: dita
Subject: [dita] Vertical Industry Vocabulary in DITA 1.3

[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
-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com


---------------------------------------------------------------------
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_workgroups.php 





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