[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]