OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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