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