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

["Eliot Kimber" <ekimber@reallysi.com>]

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