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

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

I too had qualms about the word "claim" but I may not have voiced them.
It is legitimate semantics for the marketing of tools, so it is relevant
to the TC's role adjudicating conformance to the spec.

Here's my attempt to summarize this discussion for myself. Maybe it can
be useful.

Within the spec, the terms "DITA aware" and "specialization aware" are
redundant. The relevant distinction is whether a tool is conforming or
not. As you say, Eliot, if a tool makes no claim to support DITA, the
question of conformity does not arise. We don't even have to be
concerned that it makes no claim. Any claim that a vendor does make is
only meaningful as a claim to be DITA conforming.

We may further identify a subset of features which are supported in a
conforming way (where the entire spec is the limiting case). And there's
the rub. "DITA aware" and "specialization aware" are marketing terms
that fog the question of how fully a tool conforms to the spec. They are
useful only to a vendor that wants to claim that their tool supports
DITA even though they cannot demonstrate full conformity. 

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.

> We have already established that it is not realistically 
> possible in the 1.2 time frame to define an enumerated set of 
> features in order to then label them as required, optional, etc.

A few months ago, I asked JoAnn and others if there was a list of 1.2
features. I had gone through threads on the dita alias and gleaned a
list. The Adoption TC is using that list now. Maybe it would be feasible
even within our time constraints to confirm its completeness?

My thinking: A list of features is useful to vendors because it helps to
level the marketing field, but it is not essential for the TC when it is
called upon to judge partial conformance. Further, since the DITA TC is
the adjudicating body, and because the standard of judgement is the spec
and not any feature list derived from the spec, we are empowered to
refine the feature list over time based on experience with the
adjudication process. 

This presumes that we do have a process in place that brings vendors
before us for judgement of their marketing claims (there's that word). 

	/Bruce

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Sunday, February 21, 2010 10:55 PM
> To: Dick Hamilton; dita
> Subject: Re: [dita] Use of "claims to be DITA aware": Why I 
> Said It Like That
> 
> On 2/21/10 7:03 PM, "Dick Hamilton" <rlhamilton@frii.com> wrote:
> 
> > Eliot,
> > 
> > I was one of those who commented on "claims to be DITA aware."
> > 
> > I think the thing that tripped me up was the second sentence under 
> > "Conformance of Processors," "A processor is DITA-aware if 
> it claims 
> > to implement DITA-specific processing beyond that required 
> to process 
> > XML documents in general." Given that definition, my blender is 
> > DITA-aware if I claim that it is. I don't see the utility 
> in defining 
> > a term that doesn't have some substantive meaning.
> 
> If your blender claims to be DITA aware then I can 
> legitimately judge its conformance to the DITA standard (I 
> suspect it would not conform). If it does not make such a 
> claim, then I cannot judge it's conformance.
> 
> Note that I'm *NOT* saying that processors claim that they do 
> or don't conform--that is for us to judge based on the 
> requirements of the spec. I'm saying that they claim that 
> they are or are not DITA-aware.
> 
> > While I see your point about a claim being necessary, the way it's 
> > stated in the conformance statement is not what I think you 
> meant, and 
> > in any case is more complex than it needs to be.
> 
> I will review the language and see if I can express the 
> requirement that processors either claim or don't claim DITA 
> awareness.
> 
> > I suggest a different strategy to use in place of the 
> description of 
> > "claims to be DITA aware.". Why not make one requirement of a 
> > conforming DITA-aware or DITA-specialization-aware processor be a 
> > statement as to which features of DITA it supports?  Without the 
> > statement, a processor by definition cannot be considered 
> conforming, 
> > which I think addresses your concern. In addition, 
> potential users get 
> > a statement of what the tool supports. Given how broadly 
> > non-specialization-aware processor is defined, such a 
> statement would be really helpful (I'd argue essential).
> 
> The problem with requiring processors to state which features 
> of DITA they support is that there is in fact no definitive 
> list of features to which such a list could refer, as there 
> is for example for XSL-FO, where the standard is both 
> organized as a set of features and explicitly indicates which 
> features are required for conformance at a specific level.
> 
> DITA is not currently defined in that way and may never be.
> 
> Therefore, the best we can do is distinguish processors that 
> claim to be DITA aware from those that do not.
> 
> We have already established that it is not realistically 
> possible in the 1.2 time frame to define an enumerated set of 
> features in order to then label them as required, optional, etc.
> 
> Cheers,
> 
> E.
> 
> 
> > 
> > I hope that helps.
> > 
> > Dick Hamilton
> > ---------------------------------
> > XML Press
> > XML for Technical Communicators
> > http://xmlpress.net
> > (970) 231-3624
> > 
> > 
> >> -----Original Message-----
> >> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> >> Sent: Sunday, February 21, 2010 10:28 AM
> >> To: dita
> >> Subject: [dita] Use of "claims to be DITA aware": Why I 
> Said It Like 
> >> That
> >> 
> >> 
> >> Some of the comments on the latest conformance topic were to the 
> >> effect that phases like "claims to be DITA aware" should 
> be changed 
> >> to something else.
> >> 
> >> My use of "claims to be" was very deliberate.
> >> 
> >> My reasoning is that one can only judge the DITA 
> conformance of tools 
> >> that claim to be DITA aware. This is because, as an XML 
> application, 
> >> *any* XML processor can do useful things with DITA content 
> but only 
> >> those that *claim* to be DITA-aware processors can be held to the 
> >> conformance requirements of the DITA spec.
> >> 
> >> That is, just because a given processor happens to process DITA 
> >> content does not, by itself, impose DITA conformance 
> requirements on 
> >> that processor.
> >> 
> >> This is something I learned from being a judge at an amateur beer 
> >> brewing
> >> competition: the beer is judged on the category the brewer 
> places it 
> >> in, not the category the judges *think* it should have been placed 
> >> in. Thus, if a brewer places what's obviously a porter in 
> the lager 
> >> category, it must be judged by the rules for lagers, not the rules 
> >> for porters.
> >> 
> >> So it is with processors handling DITA content: a 
> processor can only 
> >> be judged on DITA conformance if the processor asserts 
> that it is in 
> >> fact a DITA-aware processor.
> >> 
> >> That is, there is no useful sense in which a given 
> processor is or is 
> >> not DITA conforming without first determining whether or not the 
> >> processor considers itself to be DITA aware.
> >> 
> >> If a processor does not claim DITA awareness it falls outside the 
> >> purview of the DITA spec and cannot be judged to be either DITA 
> >> conforming or non-conforming, because DITA conformance is not 
> >> relevant. We may be able to determine that such a tool *would or 
> >> would not* be a conforming DITA processor but it would be 
> >> inappropriate to say that such a processor is or is not a 
> conforming 
> >> DITA processor. It is simply not a DITA-aware processor.
> >> 
> >> In particular, it is important for DITA users to 
> understand that they 
> >> MAY NOT describe a given XML processor as 
> non-DITA-conforming unless 
> >> that processor explicitly claims to be DITA aware.
> >> 
> >> For example, an XML editor that does not claim to be DITA aware 
> >> should not be described as a non-conforming DITA 
> application. It MAY 
> >> be described as a non-DITA-aware application (because it has not 
> >> claimed to be DITA aware).
> >> 
> >> By the same token, if a processor claims to be DITA aware 
> then it may 
> >> be judged on its conformance to the DITA spec.  That is, once you 
> >> claim DITA awareness, DITA conformance is a binary check, 
> just as it 
> >> is for XML or any other similar standard. You either 
> conform or you 
> >> don't to rules for those DITA features that are relevant to the 
> >> processor.
> >> 
> >> Note that the question is not whether or not a processor claims to 
> >> *conform*, it's a question of whether or not it claim to be DITA 
> >> *aware*.
> >> Awareness requires conformance.
> >> 
> >> And just to be clear, as currently written, the conformance clause 
> >> recognizes what are effectively two levels of DITA conformance:
> >> non-specialization-aware and specialization-aware.
> >> 
> >> Non-specialiation-aware processors need only implement 
> those specific 
> >> DITA vocabulary modules (standard or not) that they want 
> to support 
> >> and need not handle any others.
> >> 
> >> Specialization-aware processors MUST process all valid 
> DITA content, 
> >> regardless of specialization, at least in terms of their 
> most general 
> >> types.
> >> [That is, a specialization-aware processor need not be 
> aware of the 
> >> specific semantics of a given specialization, only of the 
> semantics 
> >> of one of its base types.]
> >> 
> >> This implies, necessarily, that specialization-aware processors 
> >> should also be general-purpose processors, meaning that they 
> >> implement all *potentially
> >> applicable* DITA features, including conref, keyref, map 
> processing, 
> >> etc. We have no defined mechanism for saying that a given 
> conforming 
> >> specialization-aware processor implements conref but not 
> keyref, for 
> >> example.
> >> 
> >> By contrast, non-specialization-aware processors, because they are 
> >> necessarily bound to specific vocabulary modules, need 
> only implement 
> >> those features actually used by those modules.
> >> 
> >> Because a given vocabulary module can disallow markup related to 
> >> specific features (e.g., @conref, @keyref, etc.), a given 
> vocabulary 
> >> module may only require a subset of DITA features.
> >> 
> >> Said another way: the set of relevant features for 
> >> non-specialization-aware processors is defined by the set of 
> >> vocabulary modules they claim to support while the set of relevant 
> >> features for specialization-aware processors is defined by 
> the DITA 
> >> spec relative to the *type* of processing the processor does.
> >> 
> >> This distinction between specialization-aware and 
> >> non-specialization-aware allows one to create special-purpose 
> >> DITA-aware processors that correctly implement the 
> features used by 
> >> the vocabulary modules they do support without requiring all 
> >> conforming DITA processors to be completely generalized.
> >> 
> >> Consider the case of business documents: it may be useful 
> to define a 
> >> highly restricted set of vocabulary modules for business documents 
> >> that disallow both conref and keyref and define a very 
> limited set of 
> >> element types. One could then have conforming processors that 
> >> understand only these very limited vocabulary modules. 
> Assuming they 
> >> are otherwise correctly implemented, such processors would be 
> >> DITA-aware but need not be specialization aware and would 
> not need to 
> >> implement either conref or keyref.
> >> 
> >> Cheers,
> >> 
> >> Eliot
> >> 
> >> --
> >> 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
> >> 
> >> 
> > 
> > 
> 
> --
> 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 
> 
>