[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
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]