RE: [dita] Specialization support: a core philosophical issue

[Don Day <dond@us.ibm.com>]

When you say "separate specification," Eliot, do you mean a new TC
activity, or formal endorsement by the DITA TC into the overall DITA
standard?

I don't think we want to encourage the separate TC route for new
Specializations (for reasons of expense, conflict of time among
cross-attending members, confusion of leadership, and more).

Likewise, I don't think we want to devalue the SubCommittee's products
because we think their efforts have no more value than specializations
developed externally. They've paid for OASIS membership in order to develop
their industry specializations within the authority and process of OASIS,
and our process should continue to preserve that justification for their
participation.

Our charter requires us to carefully consider admitting additional core
infotypes into the scope of work, and also to define a process to recognize
additional specializations. Those subcommittees created by Resolution of
the TC represent focused activities of special value to the TC, and our TC
should continue to recognize those industry-opening opportunities. On the
other hand, our charter also allows us to develop a process to recognize
externally designed specializations. One big consideration here is
Intellectual Property--OASIS owns the ideas developed within the
SubCommittees, and presumeably those participating companies did a great
deal of Due Diligence to ensure that there would be compensating value in
the SC activity for that IP consignment. However good and useful
externally-developed specializations may be, these do NOT have to submit
their IP to OASIS, therefore we cannot brand or certify those products in
the same way.

Using some possible language for the solution I see, I suggest that we
consider a tiered approach that retains the current value for the" Approved
Specializations of the Core Specifications" of existing and future OASIS
SubCommittees, yet allows designating useful implementations as "Recognized
Specializations (or something less than Approved) of the Core
Specifications."

Regards,
--
Don Day
Chair, OASIS DITA Technical Committee
Chair, IBM DITA Architects Board
Email: dond@us.ibm.com
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-244-2868 (home office)

"Where is the wisdom we have lost in knowledge?
 Where is the knowledge we have lost in information?"
   --T.S. Eliot


                                                                           
             "Eliot Kimber"                                                
             <ekimber@reallysi                                             
             .com>                                                      To 
                                       "Michael Priestley"                 
             10/02/2007 12:02          <mpriestl@ca.ibm.com>,              
             PM                        dita@lists.oasis-open.org           
                                                                        cc 
                                                                           
                                                                   Subject 
                                       RE: [dita] Specialization support:  
                                       a core philosophical issue          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I generally agree with Michael’s analysis. The only thing I would draw
attention to is:
  “specifications for standardized specializations” as “part of the
standard”
We need to clearly define what “the standard” is in this context. Do we
mean DITA 1.2 as published, which presumes it includes a number
specializations in addition to the core base types, or do we mean any
output of any subcommittee of the DITA TC?
In general I think that the core DITA spec should only include the core
types as represented by DITA 1.1 (including bookmap and glossentry) and
that anything else should be published as a separate specification so that
it is clear what is core DITA and what is a separate, but standard,
specification.
The language around standard specializations also implies that they are
privileged but it doesn’t distinguish privilege simply because of being
standardized (by any body, not just the DITA TC) or because of being
produced by the DITA TC. I would argue that there’s no particular useful
distinction between a specialization module produced by a DITA TC
subcommittee and one produced by any other recognized standards body: they
both have to conform to the same rules and can be equally well validated
against them (to the degree that the DITA rules are validatable), unless
the DITA TC is guaranteeing that the subcommittee specs have been somehow
vetted in advance of publication to ensure their correctness of
implementation with regard to the base DITA spec. [Note that since the
current DITA spec does not have a conformance clause there’s really no
legalistic basis for saying that a given application is or isn’t valid,
even if we can determine that it is not valid technically.]
From an implementation and use standpoint, having a given specialization
module be standardized or not doesn’t really change anything: if the module
is valuable it will be used and implemented, if it’s not it won’t be,
regardless of its status as a standard. Being standardized doesn’t
guarantee long-term maintenance or acceptance.
I just want to make sure we’re clear as a committee about what we are
standardizing as distinct from what others might standardize.
(And in case it’s not clear from the above, the current DITA spec could be
usefully broken into a truly core spec that only defines map and topic,
with all of the other specializations of map and topic moved to one or more
additional specs—however, I’m not suggesting we do that for DITA 1.2, but
doing it would make it much clearer that there’s nothing stopping another
community for whom concept/task/ref isn’t useful from standardizing purely
from topic and map.)
Cheers,
E.
----
W. Eliot Kimber
Senior Solutions Architect
Really Strategies, Inc.
512 554 9368

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, October 02, 2007 11:15 AM
To: dita@lists.oasis-open.org
Subject: [dita] Specialization support: a core philosophical issue


Per today's TC meeting, summing up my thoughts on required support for the
core spec (new minimal architectural spec plus core language spec) vs for
specialization specs (new separate docs for tech content, machine
industries, etc.) vs for user specializations.

Core spec:
- all DITA implementers need to support the core specification and provide
its documented behaviors as defaults
- we need at least three documented users for the core spec, per OASIS
requirements

Standardized specializations:
- some DITA implementers may also choose to support the extended
specifications for standardized specializations and provide their
documented behaviors as defaults, including cases where the specialized
behaviors override the core defaults
- we need at least three documented users for each standardized
specialization, or it shouldn't be considered "baked" enough to become part
of the standard

User specializations outside the standard:
- where a particular user or community creates additional specializations
beyond those in the standard, they can expect default support based on
inheritance (from either the core, or from a standardized specialization if
appropriate)
- but if they want behaviors that override what they get by default, they
will need to provide those overrides themselves
- this is pretty much the same as if the user went with a vendor that
didn't support the standardized specialization they needed (ie they'll get
inherited behavior, but not specialized behavior, unless they develop it or
someone develops it for them)

Sum:
- everyone needs to support the core;
- specialized support (beyond core defaults) for the specialized parts of
the spec are optional but encouraged, and should represent an established
user community;
- specialized support (beyond core defaults or standard specialization
defaults) for non-standardized user specializations are up to the user or
their partners to provide

Philosophical point:
- specialization doesn't eliminate differences between markup languages
(although it does reduce them), it provides a framework for managing those
differences

Michael Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25