Eliot,
Have you taken a look at the DITA 1.2 TOC outline (http://wiki.oasis-open.org/dita/Draft_1.2_TOC)?
If not, you should. That was done without much consideration of approvals
and the like, but it does propose a start on breaking up the DITA specification
into core specifications and a set of specialization specifications.
We’ve had multiple specifications in the Architecture and
Language spec since 1.0, so multiple specifications in and of themselves
shouldn’t be a problem.
I think that TC subcommittees should be able to develop separate
specifications, but also think that those specifications need to be approved by
the larger TC and then by the OASIS membership before they become
official. Hopefully there is enough interaction or membership overlap
between the subcommittees and the TC so that there isn't much risk that a large
amount of work will be put in to the development of a sub-committee spec. that
the TC won't approve. Approval of a subcommittee spec by the TC would
include that spec in with whatever other specs the TC eventually sends out for
approval by the OASIS membership. It is that family of specifications once they
are approved by the OASIWS membership that becomes the DITA 1.2 (or whatever)
standard.
Or at least that is my thinking. Just remember that I am an
unofficial newcomer to the DITA TC and so may not know what I am talking about.
-Jeff
> -----Original Message-----
> From: Eliot Kimber [mailto:]
> Sent: Tuesday, October 02, 2007 4:10 PM
> To: Don Day
> Cc: ; Michael Priestley
> Subject: RE: [dita] Specialization support: a core philosophical
issue
>
> By "separate specification" I mean a document separate
from what we mean
> by DITA 1.x [what we might call "the core DITA
specification"] that is a
> physically and legally separate standard that normatively depends
on the
> core DITA spec but is not itself part of core DITA. If the
TC as
> chartered is only allowed to produce a single specification (e.g.
"DITA")
> and that means that the output of various subcommittees is, by
definition,
> part of core DITA, then I think I am suggesting that those groups
should
> be separate TCs in their own right. If our charter allows the
> subcommittees to produce independent specs then there's no
problem--they
> can do their work, taking advantage of any real or perceived added
value
> being under the TC provides, but not require the core DITA spec to
include
> that work as part of the core feature set.
>
> If the first case holds then I think we become faced with a
situation
> where we have to first define a proper conformance clause and then
use
> that clause to say that specializations X, Y, and Z are optional
and what
> optional means. Without that optionality then you end up forcing
most
> implementers to be nonconforming simply because few will be
willing or
> able to implement everything in the spec. It's easier to simply
make the
> optional stuff separate specs and make everything in the core DITA
spec
> required by definition.
>
> I think that DITA has to become a "family of standards"
that together
> represent a body of technology from which you can choose those
things you
> need, based on an invariant, required, core.
>
> There is already confusion in the community about what
"DITA" is and
> isn't. There needs to be very crisp demarcation between those
things that
> are core to DITA as a technology and those things that are
applications of
> that technology. I don't think we do that well enough today.
>
> I think there is a well-intentioned desire, both by users and by
the DITA
> developers, to include in the core spec everything that is useful
to a
> reasonable majority of the DITA community, thus the inclusion of
bookmap
> and glossentry in DITA 1.1. However well intentioned, that
approach cannot
> be sustained as the scope of application of DITA increases over
time,
> which it certainly will.
>
> From a spec development standpoint, one could argue that bookmap
and
> glossentry would have been better defined as separate
specifications in
> their own right since neither is defining any core functionality
for the
> DITA technology. But it was clearly an appropriate *marketing*
decision to
> include them because such a large majority of the current and
potential
> DITA audience needs them.
>
> But where does it stop? At some point you have to draw a line and
say
> "everything after this is a separate spec" and not part
of core DITA. I'm
> suggesting that line be drawn between 1.1 and 1.2, except for the
small
> obvious specializations we accepted or are likely to accept (e.g.,
mapref,
> text, etc.).
>
> That is, whatever is developed by the instructional design or
machine
> industry subcommittees, regardless of its value or scope of applicability,
> is, by definition, not part of core DITA. Nor would be anything
more
> general, like glossentry, that the TC identified as being
generally
> applicable.
>
> As you point out there may be significant additional value in
having a
> particular specialization be developed under the DITA TC, such as
the
> things you outline. As an interested party I am of course more
likely to
> *participate* in the development of a specification if the
governing body
> does things to add value and instill confidence (such as protect
patents
> or provide supporting infrastructure or whatever). But that
doesn't really
> change how a given specialization will be accepted in the
marketplace.
> What matters to people is whether or not its supported by the
tools they
> use. Being or not being a standard rarely drives either vendor
> implementation or user acceptance. Just saying.
>
> I tend to be a deconstructionist when it comes to specs, just as I
prefer
> layered architectures for implementation. I'd personally prefer
for the
> DITA technology to be defined as a set of layered specs, one
building on
> the next, but making it clear what's core technology
(map/topicref) and
> what is specialization (map/topicref mapgroup/topichead). Of
course, that
> approach always raises the problem of how to define clearly a combination
> of features that represent a unit of required or optional support
for
> determining conformance or compliance of applications and
implementations.
> Recognizing that I accept that the 1.1 set of features is probably
about
> as a good a compromise between precision (clear layering) and
convenience
> (one monolithic spec with no optional features) that we can have,
I will
> not push for this sort of deconstructing of the spec, but I think
it's
> useful for us to recognize that DITA as a technology does have inherent
> layers that are worth at least acknowledging even if they're not
legally
> distinguishable units of conformance or distinct specs.
>
> Cheers,
>
> E.
> ----
> W. Eliot Kimber
> Senior Solutions Architect
> Really Strategies, Inc.
> 512 554 9368
>
>
> > -----Original Message-----
> > From: Don Day [mailto:]
> > Sent: Tuesday, October 02, 2007 2:07 PM
> > To: Eliot Kimber
> > Cc: ; Michael Priestley
> > Subject: RE: [dita] Specialization support: a core
philosophical issue
> >
> > 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:
> > 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
<>,
> >
PM
> >
> > 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:]
> > Sent: Tuesday, October 02, 2007 11:15 AM
> > To:
> > 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
> >
> > http://dita.xml.org/blog/25
