Re: [dita] Use of "claims to be DITA aware": Why I Said It Like That

[Eliot Kimber <ekimber@reallysi.com>]

On 2/22/10 11:46 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:

> Within the spec, the terms "DITA aware" and "specialization aware" are
> redundant. The relevant distinction is whether a tool is conforming or
> not.

That's exactly the opposite of what I'm saying: "DITA-aware" does *not*
imply specialization aware. DITA-aware merely means that the processor can
handle documents conforming to *at least one* conforming DITA document type,
as specified by the processor, but need not support any features not
required by that document type.

Specialization-aware is a further, more-demanding class of processor that is
able to handle any document specialized from some set of supported
vocabulary modules and with, possibly, the required use of specific
constraint modules.

The most complete DITA implementation would be a "fully DITA aware"
processor that supports all base vocabulary modules without constraint,
which implies support for all non-vocabulary-specific DITA features, such as
conref and keyref.

Thus "DITA aware" and "specialization aware" are not redundant and neither,
by itself, implies support for any particular feature of DITA.

> Perhaps the remedy is to establish the legitimacy of partial
> conformity--e.g. we don't support feature x but that doesn't matter
> because our customers don't use or care about feature x.

Processors can formally indicate the set of features they support through
the set of vocabulary modules they allow and the set of constraint modules
they *require*. Because all DITA features are ultimately accessed through
specific markup constructs, allowing or disallowing a specific construct
determines whether the feature is or is not supported (or rather, whether or
not a given document can use that feature).

In particular, a processor that does not support a particular feature must
require the use of constraint modules that disallow the use of the markup
constructs that use that feature, e.g., the conref attributes if a processor
doesn't support conref or the xref element if it doesn't support cross
reference processing.

For DITA-aware but not specialization-aware processors this translates into
a specification of the set of DITA *document types* the processor supports,
since DITA document types are, by definition, unique sets of vocabulary and
constraint modules.

For DITA-aware but specialization-aware processors this translates into a
specification of the set of base vocabulary modules supported (e.g., map,
topic, or both map and topic, at a minimum) and the set of constraint
modules that are *required*, meaning that any DITA document must include as
part of is DITA document type the appropriate required constraint module or
modules.

A processor that supports all base modules and does not require any
constraint modules implicitly supports the full DITA feature set to degree a
given feature is relevant to that processor.

Thus, processors have a well-defined, unambiguous way to define precisely
which features they do or don't support through the use of constraint
modules.


-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com