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

["Dick Hamilton" <rlhamilton@frii.com>]

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.

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 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).

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