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
