[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
As the person who lit the fuse (or at least fanned the flames), I apologize for not making the meeting this morning; I've been fighting a cold and slept right through the meeting. I'm glad you had a productive meeting and are on track to get a good conformance statement. Best, Dick Hamilton --------------------------------- XML Press XML for Technical Communicators http://xmlpress.net (970) 231-3624 > -----Original Message----- > From: Eliot Kimber [mailto:ekimber@reallysi.com] > Sent: Tuesday, February 23, 2010 10:15 AM > To: Bruce Nevin (bnevin); dita > Subject: Re: [dita] Use of "claims to be DITA aware": Why I > Said It Like That > > > On 2/23/10 11:13 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote: > > > For the record, the conclusions taken on today's TC call have well > > answered my concern about vague and ill-defined terms. It > doesn't matter > > whether vendors call it awareness, osmosis, or grokking, so long as > > their customers can refer to conformance claims that they > can verify. > > Helping them with the means to verify is a task (primarily) for the > > Adoption TC. > > Cool. Hopefully my rework of the conformance spec will meet with your > approval. > > Cheers, > > E. > > > > > /Bruce > > > >> -----Original Message----- > >> From: Bruce Nevin (bnevin) > >> Sent: Monday, February 22, 2010 2:54 PM > >> To: Eliot Kimber; Dick Hamilton; dita > >> 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 > >>> > >>> > >> > >> > --------------------------------------------------------------------- > >> 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 > >> > >> > > > > > --------------------------------------------------------------------- > > 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_workgroups.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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]