I was traveling all of last week so I apologize for the
delay in getting this issue out on the list. During developer days, CPE
name deprecation was the primary point of contention relating to the CPE 2.3
Dictionary specification. Specifically, there were issues raised relating
to the need to support one-to-many deprecation for capturing the growth of information
relative to a single CPE name.
By the end of the session, it seemed to me that three
deprecation relationships existed (I think we only talked about two, but I am
adding CPE Name Removal as a third). I have listed these deprecation
Name Correction - A syntax error occurred (e.g. typo, misspelling)
during name creation and the name must be updated to fix this error. This
type of deprecation is one-to-one, with the deprecated CPE name pointing
to the new name that represents the same product, but with the syntax error
Name Removal - A name exists in the dictionary that does not belong and
has no replacement. This condition normally results in the case where the
dictionary maintainer makes an error that cannot be corrected with a new name
(i.e. the name should never have been included in the dictionary). In
this case, the name will be deprecated without pointing to a new name.
Information Discovery - One or more CPE names are added to the
dictionary that are more complete than an existing CPE name within the
dictionary. For example, 'cpe-23:/a:adobe:acrobat:3.0:-:*:*:*:*:*:*'
are added to a dictionary containing the name 'cpe-23:/a:adobe:acrobat:3.0:*:*:*:*:*:*:*'. In
this example, the two names that are added provide more information (i.e.
update component value) than the existing name in the dictionary. In
this case, the pre-existing name really represented a set of possible products
that were not known about when the name was originally added to the
dictionary. This type of deprecation must be one-to-many since the
pre-existing name is deprecated to all of the names that are more
complete. This deprecation relationship is largely informational, when
making this deprecation the dictionary maintainer is asserting any CPE name
within the set of new CPE names is a valid replacement for the deprecated CPE
name; it is up to the dictionary user to decide on which individual name to
use, or to use the entire set.
Supporting these distinct relationships within the XSD model
is trivial. I am planning on adding a 'type' attribute to the
'deprecated-by' element to capture the deprecation type. This attribute
would take a value from enumerated list containing the three distinct types.