OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]