Use of "claims to be DITA aware": Why I Said It Like That

[Eliot Kimber <ekimber@reallysi.com>]

Some of the comments on the latest conformance topic were to the effect that
phases like "claims to be DITA aware" should be changed to something else.

My use of "claims to be" was very deliberate.

My reasoning is that one can only judge the DITA conformance of tools that
claim to be DITA aware. This is because, as an XML application, *any* XML
processor can do useful things with DITA content but only those that *claim*
to be DITA-aware processors can be held to the conformance requirements of
the DITA spec.

That is, just because a given processor happens to process DITA content does
not, by itself, impose DITA conformance requirements on that processor.

This is something I learned from being a judge at an amateur beer brewing
competition: the beer is judged on the category the brewer places it in, not
the category the judges *think* it should have been placed in. Thus, if a
brewer places what's obviously a porter in the lager category, it must be
judged by the rules for lagers, not the rules for porters.

So it is with processors handling DITA content: a processor can only be
judged on DITA conformance if the processor asserts that it is in fact a
DITA-aware processor.

That is, there is no useful sense in which a given processor is or is not
DITA conforming without first determining whether or not the processor
considers itself to be DITA aware.

If a processor does not claim DITA awareness it falls outside the purview of
the DITA spec and cannot be judged to be either DITA conforming or
non-conforming, because DITA conformance is not relevant. We may be able to
determine that such a tool *would or would not* be a conforming DITA
processor but it would be inappropriate to say that such a processor is or
is not a conforming DITA processor. It is simply not a DITA-aware processor.

In particular, it is important for DITA users to understand that they MAY
NOT describe a given XML processor as non-DITA-conforming unless that
processor explicitly claims to be DITA aware.

For example, an XML editor that does not claim to be DITA aware should not
be described as a non-conforming DITA application. It MAY be described as a
non-DITA-aware application (because it has not claimed to be DITA aware).

By the same token, if a processor claims to be DITA aware then it may be
judged on its conformance to the DITA spec.  That is, once you claim DITA
awareness, DITA conformance is a binary check, just as it is for XML or any
other similar standard. You either conform or you don't to rules for those
DITA features that are relevant to the processor.

Note that the question is not whether or not a processor claims to
*conform*, it's a question of whether or not it claim to be DITA *aware*.
Awareness requires conformance.

And just to be clear, as currently written, the conformance clause
recognizes what are effectively two levels of DITA conformance:
non-specialization-aware and specialization-aware.

Non-specialiation-aware processors need only implement those specific DITA
vocabulary modules (standard or not) that they want to support and need not
handle any others. 

Specialization-aware processors MUST process all valid DITA content,
regardless of specialization, at least in terms of their most general types.
[That is, a specialization-aware processor need not be aware of the specific
semantics of a given specialization, only of the semantics of one of its
base types.]

This implies, necessarily, that specialization-aware processors should also
be general-purpose processors, meaning that they implement all *potentially
applicable* DITA features, including conref, keyref, map processing, etc. We
have no defined mechanism for saying that a given conforming
specialization-aware processor implements conref but not keyref, for
example.

By contrast, non-specialization-aware processors, because they are
necessarily bound to specific vocabulary modules, need only implement those
features actually used by those modules.

Because a given vocabulary module can disallow markup related to specific
features (e.g., @conref, @keyref, etc.), a given vocabulary module may only
require a subset of DITA features.

Said another way: the set of relevant features for non-specialization-aware
processors is defined by the set of vocabulary modules they claim to support
while the set of relevant features for specialization-aware processors is
defined by the DITA spec relative to the *type* of processing the processor
does.

This distinction between specialization-aware and non-specialization-aware
allows one to create special-purpose DITA-aware processors that correctly
implement the features used by the vocabulary modules they do support
without requiring all conforming DITA processors to be completely
generalized.

Consider the case of business documents: it may be useful to define a highly
restricted set of vocabulary modules for business documents that disallow
both conref and keyref and define a very limited set of element types. One
could then have conforming processors that understand only these very
limited vocabulary modules. Assuming they are otherwise correctly
implemented, such processors would be DITA-aware but need not be
specialization aware and would not need to implement either conref or
keyref. 

Cheers,

Eliot   

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