I do not mean they are redundant with each other. I mean that each term
is redundant, supernumary, unneeded, making no useful semantic
contribution (except for marketing purposes by vendors as noted).
The question is not so much about determining what a given tool
supports. It is about making vendors' marketing claims answerable.
> -----Original Message-----
> From: Eliot Kimber [mailto:]
> Sent: Monday, February 22, 2010 2:27 PM
> To: Bruce Nevin (bnevin); Dick Hamilton; dita
> Subject: Re: [dita] Use of "claims to be DITA aware": Why I
> Said It Like That
>
> On 2/22/10 11:46 AM, "Bruce Nevin (bnevin)" <> 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
>
>
