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