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


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]