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

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

For the record, the conclusions taken on today's TC call have well
answered my concern about vague and ill-defined terms. It doesn't matter
whether vendors call it awareness, osmosis, or grokking, so long as
their customers can refer to conformance claims that they can verify.
Helping them with the means to verify is a task (primarily) for the
Adoption TC.

	/Bruce 

> -----Original Message-----
> From: Bruce Nevin (bnevin) 
> Sent: Monday, February 22, 2010 2:54 PM
> To: Eliot Kimber; Dick Hamilton; dita
> 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
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS 
> TC that generates this mail.  Follow this link to all your 
> TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>