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