Re: thoughts on documentation reuse.

[Randy Presuhn <rpresuhn@dorothy.bmc.com>]

[ post by non-subscriber ]

Hi -

> Message-Id: <5.1.0.14.2.20020323163423.0240cbd8@fedex.cisco.com>
> Date: Sat, 23 Mar 2002 16:57:54 -0800
> To: Wes Hardaker <wes@hardakers.net>
> From: Andy Bierman <abierman@cisco.com>
> Subject: Re: thoughts on documentation reuse.
> Cc: sming@ops.ietf.org
> In-Reply-To: <sd3cyrqiv2.fsf@wanderer.hardakers.net>
> References: <5.1.0.14.2.20020322181044.0244cd90@fedex.cisco.com>
>  <5.1.0.14.2.20020322181044.0244cd90@fedex.cisco.com>
...
> As we start using more complex TYPEDEFs instead of simple TCs,
> some changes may be needed:
> 
> 1) Versioning
>    TYPEDEFs may need a version field embedded in the name,
>    or perhaps identified in a VERSION or LAST-UPDATED clause for the type.
>    FooTypeV0 would represent a type in a work-in-progress.
>    FooTypeV1 would be the initial version of the type.
>    If the type is changed or extended over time, FooTypeV2, etc.,
>    would be published (and FooTypeV1 deprecated). Many times
>    the user doesn't care, so FooType would refer to the most recent
>    version of the type.  MODULE-COMPLIANCE info may need to be added
>    to identify the exact version used in a particular MIB version.
...

An interesting characterstic (I'm not sure whether it's a
bug or a feature) of providing an "expanded" version of a
specification is that it will reflect whatever versions of
all the bits and pieces were current at the time the
expansion happened.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------