RE: [dita] RE: Vertical Industry Vocabulary in DITA 1.3

["Su-Laine Yeo" <su-laine.yeo@justsystems.com>]

Wholeheartedly agree. Eliot is bang-on here. 

And purely from a social-engineering perspective, splitting people up
into small groups by industry will let the groups act as models and
rivals to each other. Groups will learn from other groups what works and
doesn't work, and if we're lucky they will compete with each other to be
the best group.

One thing though that the DITA TC could do is make sure that vocabulary
modules do not conflict with each other. E.g. if two specializations
define the same element name with different meanings, that would be a
problem for anyone trying to use both specializations at the same time. 

Su-Laine


Su-Laine Yeo
Solutions Consultant 
JustSystems Canada, Inc.
Office: 1 (778) 327-6356 
syeo@justsystems.com

XMetaL Community Forums: http://forums.xmetal.com
For partners only: http://www.justpartnercenter.com



-----Original Message-----
From: bryan.s.schnabel@tektronix.com
[mailto:bryan.s.schnabel@tektronix.com] 
Sent: Wednesday, February 23, 2011 9:28 AM
To: ekimber@reallysi.com; dita@lists.oasis-open.org
Subject: [dita] 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 




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