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

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:ekimber@reallysi.com]

> Sent: Tuesday, October 02, 2007 4:10 PM

> To: Don Day

> Cc: dita@lists.oasis-open.org; 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:dond@us.ibm.com]

> > Sent: Tuesday, October 02, 2007 2:07 PM

> > To: Eliot Kimber

> > Cc: dita@lists.oasis-open.org; 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: 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

dita message