[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
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:ekimber@reallysi.com] > 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)" <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]