Slides for today's webcon

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Slides for today's webcon

Brant Cheikes

We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


CPE_Webcon_May14_Final.pptx (1M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Slides for today's webcon

Brant Cheikes

All,

 

Presentation materials and recorded audio from last Friday’s CPE developer day web conference are now available here: http://cpe.mitre.org/community/dev_days.html

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Friday, May 14, 2010 11:12 AM
To: cpe-discussion-list CPE Community Forum
Subject: [CPE-DISCUSSION-LIST] Slides for today's webcon

 

We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

Reply | Threaded
Open this post in threaded view
|

Re: Slides for today's webcon

Berkebile, Brenda G
In reply to this post by Brant Cheikes
Please forgive me for coming to the party late.   I have questions relating to the version and editions segments.  The following Formatted String Binding example was provided:
 
cpe-2.3:/a:adobe:acrobat++:9.2:-:*:-:-:x64:-
 
Wouldn't the release version and minor version be separated to clearly identify all subsequent versions of a release?  As in the example, ':9.2:' would be separated as ':9:2:'  Why wouldn't segmenting the version be handled at the matching level?  Perhaps I missed a previous discussion in this regard or misunderstand.
 
Please provide content examples that would represent sw_edition, target_sw, other_edition.  Would sw_edition include "Standard", "Professional", et. al.?  Would target_sw refer to the required component that may be indicated as "...for Microsoft SQL"?
 
I do like the distinction between the "$" and the "*", very useful.
 
Regards,
Brenda


From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Friday, May 14, 2010 10:12 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Slides for today's webcon

We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
Reply | Threaded
Open this post in threaded view
|

Re: Slides for today's webcon

Brant Cheikes

Brenda,

 

Regarding versioning, it turns out that this is a complex issue that we weren’t able to properly address in 2.3 due to time constraints.  First, it’s not clear what partitioning of version data to standardize on.  We heard suggestions ranging from two (major, minor), to six (major, minor, subminor, build, …).  There’s lots of inconsistency in the ways vendors version their products, and where to draw a line between “version” and “update” information (if even such a line should be drawn).  We’ve tried to partially address this in 2.3 by introducing a capability for within-component matching (single and multi-character wildcards) with the thought that this could be an 80% solution.  The need to maintain backward compatibility with 2.2 also limits our flexibility.  I expect that we will be able to provide a much more satisfactory representation of version information once we move on to a 3.0 major release.

 

You’re on the right track re the new edition-related distinctions.  The concept behind sw_edition is that it captures those elements of the product description which relate to how the product is tailored to a particular market or class of end users—“Home”, “Professional”, “Student”, etc. (as you guessed).  The concept behind target_sw is that it captures those elements of the product description which relate to the software computing environment within which the product operates—as you guessed, “for Windows”, “for MacOS”, “for Oracle 9”, etc.  The concept behind target_hw is that it captures those elements of the product description related to the physical computing platform, e.g., “x32”, “x64”, “sparc”, etc.

 

At the Naming level of the specification stack, we are simply introducing these new attributes and giving them informal definitions (as above).  When it comes to managing dictionary content, I imagine that dictionary curators will develop “valid values lists” and refine them over time.  That is, curators will build reusable term lists for the various values of sw_edition, target_sw, and target_hw, rather than just putting in whatever they feel like on a given day.

 

I’m sure you’ve warmed Paul Cichonski’s heart regarding the dollar sign!  He’s leading the Dictionary work and we’re all still trying to come to some consensus re whether or not to make the distinction explicit.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Berkebile, Brenda G [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 9:00 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

 

Please forgive me for coming to the party late.   I have questions relating to the version and editions segments.  The following Formatted String Binding example was provided:

 

cpe-2.3:/a:adobe:acrobat++:9.2:-:*:-:-:x64:-

 

Wouldn't the release version and minor version be separated to clearly identify all subsequent versions of a release?  As in the example, ':9.2:' would be separated as ':9:2:'  Why wouldn't segmenting the version be handled at the matching level?  Perhaps I missed a previous discussion in this regard or misunderstand.

 

Please provide content examples that would represent sw_edition, target_sw, other_edition.  Would sw_edition include "Standard", "Professional", et. al.?  Would target_sw refer to the required component that may be indicated as "...for Microsoft SQL"?

 

I do like the distinction between the "$" and the "*", very useful.

 

Regards,

Brenda

 


From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Friday, May 14, 2010 10:12 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Slides for today's webcon

We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
Reply | Threaded
Open this post in threaded view
|

Re: Slides for today's webcon

Berkebile, Brenda G
Brant,
 
Thanks for the prompt response.  The versioning is complex.  Before I learned of CPE, I had devised a similar practice around software component titles that would meet the needs of our organization and the varying levels of interest in the product data.  I used 3 values to represent the version,  Release/Major, Minor, and Fix/Update, which have met the needs of all areas tracking, counting, supporting, recording and purchasing all software components.  There are many right and wrong ways to work with versions, this is just an example of how it worked for our large enterprise.
 
Please provide the elements that may be represented in the other_edition distinction.
 
In regard to the distinction between the dollar sign and asterisk, there is significant value in knowing that an element is not known.  I interpret this as the dollar sign indicating that the element was investigated, but not found.  Along the same lines that blank and null can have different meanings in data elements.
 
Regards,
Brenda

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 8:28 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Brenda,

 

Regarding versioning, it turns out that this is a complex issue that we weren’t able to properly address in 2.3 due to time constraints.  First, it’s not clear what partitioning of version data to standardize on.  We heard suggestions ranging from two (major, minor), to six (major, minor, subminor, build, …).  There’s lots of inconsistency in the ways vendors version their products, and where to draw a line between “version” and “update” information (if even such a line should be drawn).  We’ve tried to partially address this in 2.3 by introducing a capability for within-component matching (single and multi-character wildcards) with the thought that this could be an 80% solution.  The need to maintain backward compatibility with 2.2 also limits our flexibility.  I expect that we will be able to provide a much more satisfactory representation of version information once we move on to a 3.0 major release.

 

You’re on the right track re the new edition-related distinctions.  The concept behind sw_edition is that it captures those elements of the product description which relate to how the product is tailored to a particular market or class of end users—“Home”, “Professional”, “Student”, etc. (as you guessed).  The concept behind target_sw is that it captures those elements of the product description which relate to the software computing environment within which the product operates—as you guessed, “for Windows”, “for MacOS”, “for Oracle 9”, etc.  The concept behind target_hw is that it captures those elements of the product description related to the physical computing platform, e.g., “x32”, “x64”, “sparc”, etc.

 

At the Naming level of the specification stack, we are simply introducing these new attributes and giving them informal definitions (as above).  When it comes to managing dictionary content, I imagine that dictionary curators will develop “valid values lists” and refine them over time.  That is, curators will build reusable term lists for the various values of sw_edition, target_sw, and target_hw, rather than just putting in whatever they feel like on a given day.

 

I’m sure you’ve warmed Paul Cichonski’s heart regarding the dollar sign!  He’s leading the Dictionary work and we’re all still trying to come to some consensus re whether or not to make the distinction explicit.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Berkebile, Brenda G [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 9:00 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

 

Please forgive me for coming to the party late.   I have questions relating to the version and editions segments.  The following Formatted String Binding example was provided:

 

cpe-2.3:/a:adobe:acrobat++:9.2:-:*:-:-:x64:-

 

Wouldn't the release version and minor version be separated to clearly identify all subsequent versions of a release?  As in the example, ':9.2:' would be separated as ':9:2:'  Why wouldn't segmenting the version be handled at the matching level?  Perhaps I missed a previous discussion in this regard or misunderstand.

 

Please provide content examples that would represent sw_edition, target_sw, other_edition.  Would sw_edition include "Standard", "Professional", et. al.?  Would target_sw refer to the required component that may be indicated as "...for Microsoft SQL"?

 

I do like the distinction between the "$" and the "*", very useful.

 

Regards,

Brenda

 


From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Friday, May 14, 2010 10:12 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Slides for today's webcon

We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
Reply | Threaded
Open this post in threaded view
|

Re: Slides for today's webcon

Brant Cheikes

At this late stage in the preparation of 2.3, I doubt we can break the version field out into multiple parts.  That said, I wonder whether we could define a content-management principle to standardize on, say, the “.” (period) as the separator between each element of a version string.  This is the typical case, though there are probably some outliers.  This might mean deprecating some number of names in which different parts of the version field are delimited with other characters, but that might be doable.  Then we get most of what we need with the single/multi-character wildcards.

 

Re other_edition, I don’t have any good examples and we may well drop it.  It was originally tossed in as a lagniappe.

 

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Berkebile, Brenda G [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 9:50 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

 

Brant,

 

Thanks for the prompt response.  The versioning is complex.  Before I learned of CPE, I had devised a similar practice around software component titles that would meet the needs of our organization and the varying levels of interest in the product data.  I used 3 values to represent the version,  Release/Major, Minor, and Fix/Update, which have met the needs of all areas tracking, counting, supporting, recording and purchasing all software components.  There are many right and wrong ways to work with versions, this is just an example of how it worked for our large enterprise.

 

Please provide the elements that may be represented in the other_edition distinction.

 

In regard to the distinction between the dollar sign and asterisk, there is significant value in knowing that an element is not known.  I interpret this as the dollar sign indicating that the element was investigated, but not found.  Along the same lines that blank and null can have different meanings in data elements.

 

Regards,

Brenda


From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 8:28 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Brenda,

 

Regarding versioning, it turns out that this is a complex issue that we weren’t able to properly address in 2.3 due to time constraints.  First, it’s not clear what partitioning of version data to standardize on.  We heard suggestions ranging from two (major, minor), to six (major, minor, subminor, build, …).  There’s lots of inconsistency in the ways vendors version their products, and where to draw a line between “version” and “update” information (if even such a line should be drawn).  We’ve tried to partially address this in 2.3 by introducing a capability for within-component matching (single and multi-character wildcards) with the thought that this could be an 80% solution.  The need to maintain backward compatibility with 2.2 also limits our flexibility.  I expect that we will be able to provide a much more satisfactory representation of version information once we move on to a 3.0 major release.

 

You’re on the right track re the new edition-related distinctions.  The concept behind sw_edition is that it captures those elements of the product description which relate to how the product is tailored to a particular market or class of end users—“Home”, “Professional”, “Student”, etc. (as you guessed).  The concept behind target_sw is that it captures those elements of the product description which relate to the software computing environment within which the product operates—as you guessed, “for Windows”, “for MacOS”, “for Oracle 9”, etc.  The concept behind target_hw is that it captures those elements of the product description related to the physical computing platform, e.g., “x32”, “x64”, “sparc”, etc.

 

At the Naming level of the specification stack, we are simply introducing these new attributes and giving them informal definitions (as above).  When it comes to managing dictionary content, I imagine that dictionary curators will develop “valid values lists” and refine them over time.  That is, curators will build reusable term lists for the various values of sw_edition, target_sw, and target_hw, rather than just putting in whatever they feel like on a given day.

 

I’m sure you’ve warmed Paul Cichonski’s heart regarding the dollar sign!  He’s leading the Dictionary work and we’re all still trying to come to some consensus re whether or not to make the distinction explicit.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Berkebile, Brenda G [mailto:[hidden email]]
Sent: Wednesday, May 19, 2010 9:00 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

 

Please forgive me for coming to the party late.   I have questions relating to the version and editions segments.  The following Formatted String Binding example was provided:

 

cpe-2.3:/a:adobe:acrobat++:9.2:-:*:-:-:x64:-

 

Wouldn't the release version and minor version be separated to clearly identify all subsequent versions of a release?  As in the example, ':9.2:' would be separated as ':9:2:'  Why wouldn't segmenting the version be handled at the matching level?  Perhaps I missed a previous discussion in this regard or misunderstand.

 

Please provide content examples that would represent sw_edition, target_sw, other_edition.  Would sw_edition include "Standard", "Professional", et. al.?  Would target_sw refer to the required component that may be indicated as "...for Microsoft SQL"?

 

I do like the distinction between the "$" and the "*", very useful.

 

Regards,

Brenda

 


From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Friday, May 14, 2010 10:12 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Slides for today's webcon

We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 



This e-mail, including attachments, may include confidential and/or

proprietary information, and may be used only by the person or entity

to which it is addressed. If the reader of this e-mail is not the intended

recipient or his or her authorized agent, the reader is hereby notified

that any dissemination, distribution or copying of this e-mail is

prohibited. If you have received this e-mail in error, please notify the

sender by replying to this message and delete this e-mail immediately.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
Reply | Threaded
Open this post in threaded view
|

Re: Slides for today's webcon

shanford
Re: [CPE-DISCUSSION-LIST] Slides for today's webcon FWIW, standardizing on the ‘.’ character and removing the other_edition proposal from 2.3 will make complex product version schemes like IOS difficult to break down into constituent parts. {e.g. 12.3(8)SXT11a}

We’re not alone, of course. The majority of Hitachi products (e.g. Cosminexus Application server 05-01-/A), and more complex firmware designations like 3Com 4500 series switches like V3.01.00s168p01 could benefit from not standardizing on ‘.’ or doing away with the other_edition capability.

Thanks,
Seth Hanford

On 5/20/10 9:33 AM, "Cheikes, Brant A." <bcheikes@...> wrote:

At this late stage in the preparation of 2.3, I doubt we can break the version field out into multiple parts.  That said, I wonder whether we could define a content-management principle to standardize on, say, the “.” (period) as the separator between each element of a version string.  This is the typical case, though there are probably some outliers.  This might mean deprecating some number of names in which different parts of the version field are delimited with other characters, but that might be doable.  Then we get most of what we need with the single/multi-character wildcards.
 
Re other_edition, I don’t have any good examples and we may well drop it. It was originally tossed in as a lagniappe.
 
/Brant
 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


From: Berkebile, Brenda G [[hidden email]]
Sent: Wednesday, May 19, 2010 9:50 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Brant,

Thanks for the prompt response.  The versioning is complex.  Before I learned of CPE, I had devised a similar practice around software component titles that would meet the needs of our organization and the varying levels of interest in the product data.  I used 3 values to represent the version, Release/Major, Minor, and Fix/Update, which have met the needs of all areas tracking, counting, supporting, recording and purchasing all software components.  There are many right and wrong ways to work with versions, this is just an example of how it worked for our large enterprise.

Please provide the elements that may be represented in the other_edition distinction.

In regard to the distinction between the dollar sign and asterisk, there is significant value in knowing that an element is not known.  I interpret this as the dollar sign indicating that the element was investigated, but not found.  Along the same lines that blank and null can have different meanings in data elements.

Regards,
Brenda



From: Cheikes, Brant A. [[hidden email]]
Sent: Wednesday, May 19, 2010 8:28 AM
To: CPE-DISCUSSION-LIST@...
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon
Brenda,
 
Regarding versioning, it turns out that this is a complex issue that we weren’t able to properly address in 2.3 due to time constraints.  First, it’s not clear what partitioning of version data to standardize on.  We heard suggestions ranging from two (major, minor), to six (major, minor, subminor, build, …). There’s lots of inconsistency in the ways vendors version their products, and where to draw a line between “version” and “update” information (if even such a line should be drawn).  We’ve tried to partially address this in 2.3 by introducing a capability for within-component matching (single and multi-character wildcards) with the thought that this could be an 80% solution.  The need to maintain backward compatibility with 2.2 also limits our flexibility.  I expect that we will be able to provide a much more satisfactory representation of version information once we move on to a 3.0 major release.
 
You’re on the right track re the new edition-related distinctions.  The concept behind sw_edition is that it captures those elements of the product description which relate to how the product is tailored to a particular market or class of end users—“Home”, “Professional”, “Student”, etc. (as you guessed).  The concept behind target_sw is that it captures those elements of the product description which relate to the software computing environment within which the product operates—as you guessed, “for Windows”, “for MacOS”, “for Oracle 9”, etc.  The concept behind target_hw is that it captures those elements of the product description related to the physical computing platform, e.g., “x32”, “x64”, “sparc”, etc.
 
At the Naming level of the specification stack, we are simply introducing these new attributes and giving them informal definitions (as above).  When it comes to managing dictionary content, I imagine that dictionary curators will develop “valid values lists” and refine them over time.  That is, curators will build reusable term lists for the various values of sw_edition, target_sw, and target_hw, rather than just putting in whatever they feel like on a given day.
 
I’m sure you’ve warmed Paul Cichonski’s heart regarding the dollar sign!  He’s leading the Dictionary work and we’re all still trying to come to some consensus re whether or not to make the distinction explicit.
 
Cheers,
/Brant
 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


From: Berkebile, Brenda G [[hidden email]]
Sent: Wednesday, May 19, 2010 9:00 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Please forgive me for coming to the party late.   I have questions relating to the version and editions segments.  The following Formatted String Binding example was provided:
 

cpe-2.3:/a:adobe:acrobat++:9.2:-:*:-:-:x64:-



Wouldn't the release version and minor version be separated to clearly identify all subsequent versions of a release?  As in the example, ':9.2:' would be separated as ':9:2:'  Why wouldn't segmenting the version be handled at the matching level?  Perhaps I missed a previous discussion in this regard or misunderstand.



Please provide content examples that would represent sw_edition, target_sw, other_edition.  Would sw_edition include "Standard", "Professional", et. al.?  Would target_sw refer to the required component that may be indicated as "...for Microsoft SQL"?



I do like the distinction between the "$" and the "*", very useful.



Regards,

Brenda



From: Cheikes, Brant A. [[hidden email]]
Sent: Friday, May 14, 2010 10:12 AM
To: CPE-DISCUSSION-LIST@...
Subject: [CPE-DISCUSSION-LIST] Slides for today's webcon
We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.
 
Cheers,
/Brant
 
Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352





This e-mail, including attachments, may include confidential and/or



proprietary information, and may be used only by the person or entity



to which it is addressed. If the reader of this e-mail is not the intended



recipient or his or her authorized agent, the reader is hereby notified



that any dissemination, distribution or copying of this e-mail is



prohibited. If you have received this e-mail in error, please notify the



sender by replying to this message and delete this e-mail immediately.


This e-mail, including attachments, may include confidential and/or

proprietary information, and may be used only by the person or entity

to which it is addressed. If the reader of this e-mail is not the intended

recipient or his or her authorized agent, the reader is hereby notified

that any dissemination, distribution or copying of this e-mail is

prohibited. If you have received this e-mail in error, please notify the

sender by replying to this message and delete this e-mail immediately.

Reply | Threaded
Open this post in threaded view
|

Re: Slides for today's webcon

Paul Cichonski
Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

I agree with Seth here, the problem we face is that different Vendors/Products version their products according to proprietary methodologies.  This is what the “Dictionary Content Management/Decisions Documents” are supposed to address, they allow dictionary maintainers to document the ways disparate vendors version their products.  This provides a mechanism to record the semantics of the version on a per product basis if necessary, so for Cisco IOS we can document what each digit in the version actually means (e.g.  major version, minor version, release, interim build number, train identifier).  This would start off as a largely paper based exercise, but I think the goal is to provide a model where we can actually capture these granular relationships, I think we even mentioned the idea at the last developer days of setting up a working group to model these more complex versioning strategies. 

 

It would be great if we could standardize on one high-level versioning scheme, but until the rest of the IT industry does I think we may lose the ability to capture meaningful information.

 

-Paul

 

From: shanford [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 9:50 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

 

FWIW, standardizing on the ‘.’ character and removing the other_edition proposal from 2.3 will make complex product version schemes like IOS difficult to break down into constituent parts. {e.g. 12.3(8)SXT11a}

We’re not alone, of course. The majority of Hitachi products (e.g. Cosminexus Application server 05-01-/A), and more complex firmware designations like 3Com 4500 series switches like V3.01.00s168p01 could benefit from not standardizing on ‘.’ or doing away with the other_edition capability.

Thanks,
Seth Hanford

On 5/20/10 9:33 AM, "Cheikes, Brant A." <bcheikes@...> wrote:

At this late stage in the preparation of 2.3, I doubt we can break the version field out into multiple parts.  That said, I wonder whether we could define a content-management principle to standardize on, say, the “.” (period) as the separator between each element of a version string.  This is the typical case, though there are probably some outliers.  This might mean deprecating some number of names in which different parts of the version field are delimited with other characters, but that might be doable.  Then we get most of what we need with the single/multi-character wildcards.
 
Re other_edition, I don’t have any good examples and we may well drop it. It was originally tossed in as a lagniappe.
 
/Brant
 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


From: Berkebile, Brenda G [[hidden email]]
Sent: Wednesday, May 19, 2010 9:50 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Brant,

Thanks for the prompt response.  The versioning is complex.  Before I learned of CPE, I had devised a similar practice around software component titles that would meet the needs of our organization and the varying levels of interest in the product data.  I used 3 values to represent the version, Release/Major, Minor, and Fix/Update, which have met the needs of all areas tracking, counting, supporting, recording and purchasing all software components.  There are many right and wrong ways to work with versions, this is just an example of how it worked for our large enterprise.

Please provide the elements that may be represented in the other_edition distinction.

In regard to the distinction between the dollar sign and asterisk, there is significant value in knowing that an element is not known.  I interpret this as the dollar sign indicating that the element was investigated, but not found.  Along the same lines that blank and null can have different meanings in data elements.

Regards,
Brenda



From: Cheikes, Brant A. [[hidden email]]
Sent: Wednesday, May 19, 2010 8:28 AM
To: CPE-DISCUSSION-LIST@...
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon
Brenda,
 
Regarding versioning, it turns out that this is a complex issue that we weren’t able to properly address in 2.3 due to time constraints.  First, it’s not clear what partitioning of version data to standardize on.  We heard suggestions ranging from two (major, minor), to six (major, minor, subminor, build, …). There’s lots of inconsistency in the ways vendors version their products, and where to draw a line between “version” and “update” information (if even such a line should be drawn).  We’ve tried to partially address this in 2.3 by introducing a capability for within-component matching (single and multi-character wildcards) with the thought that this could be an 80% solution.  The need to maintain backward compatibility with 2.2 also limits our flexibility.  I expect that we will be able to provide a much more satisfactory representation of version information once we move on to a 3.0 major release.
 
You’re on the right track re the new edition-related distinctions.  The concept behind sw_edition is that it captures those elements of the product description which relate to how the product is tailored to a particular market or class of end users—“Home”, “Professional”, “Student”, etc. (as you guessed).  The concept behind target_sw is that it captures those elements of the product description which relate to the software computing environment within which the product operates—as you guessed, “for Windows”, “for MacOS”, “for Oracle 9”, etc.  The concept behind target_hw is that it captures those elements of the product description related to the physical computing platform, e.g., “x32”, “x64”, “sparc”, etc.
 
At the Naming level of the specification stack, we are simply introducing these new attributes and giving them informal definitions (as above).  When it comes to managing dictionary content, I imagine that dictionary curators will develop “valid values lists” and refine them over time.  That is, curators will build reusable term lists for the various values of sw_edition, target_sw, and target_hw, rather than just putting in whatever they feel like on a given day.
 
I’m sure you’ve warmed Paul Cichonski’s heart regarding the dollar sign!  He’s leading the Dictionary work and we’re all still trying to come to some consensus re whether or not to make the distinction explicit.
 
Cheers,
/Brant
 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


From: Berkebile, Brenda G [[hidden email]]
Sent: Wednesday, May 19, 2010 9:00 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Please forgive me for coming to the party late.   I have questions relating to the version and editions segments.  The following Formatted String Binding example was provided:
 

cpe-2.3:/a:adobe:acrobat++:9.2:-:*:-:-:x64:-



Wouldn't the release version and minor version be separated to clearly identify all subsequent versions of a release?  As in the example, ':9.2:' would be separated as ':9:2:'  Why wouldn't segmenting the version be handled at the matching level?  Perhaps I missed a previous discussion in this regard or misunderstand.



Please provide content examples that would represent sw_edition, target_sw, other_edition.  Would sw_edition include "Standard", "Professional", et. al.?  Would target_sw refer to the required component that may be indicated as "...for Microsoft SQL"?



I do like the distinction between the "$" and the "*", very useful.



Regards,

Brenda


From: Cheikes, Brant A. [[hidden email]]
Sent: Friday, May 14, 2010 10:12 AM
To: CPE-DISCUSSION-LIST@...
Subject: [CPE-DISCUSSION-LIST] Slides for today's webcon
We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.
 
Cheers,
/Brant
 
Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352





This e-mail, including attachments, may include confidential and/or



proprietary information, and may be used only by the person or entity



to which it is addressed. If the reader of this e-mail is not the intended



recipient or his or her authorized agent, the reader is hereby notified



that any dissemination, distribution or copying of this e-mail is



prohibited. If you have received this e-mail in error, please notify the



sender by replying to this message and delete this e-mail immediately.


This e-mail, including attachments, may include confidential and/or

proprietary information, and may be used only by the person or entity

to which it is addressed. If the reader of this e-mail is not the intended

recipient or his or her authorized agent, the reader is hereby notified

that any dissemination, distribution or copying of this e-mail is

prohibited. If you have received this e-mail in error, please notify the

sender by replying to this message and delete this e-mail immediately.

Reply | Threaded
Open this post in threaded view
|

Re: Slides for today's webcon

Berkebile, Brenda G
Re: [CPE-DISCUSSION-LIST] Slides for today's webcon
Excellent!  Exactly what I'm looking for.  Where would I find this “Dictionary Content Management/Decisions Documents”?


From: Cichonski, Paul [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 9:02 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

I agree with Seth here, the problem we face is that different Vendors/Products version their products according to proprietary methodologies.  This is what the “Dictionary Content Management/Decisions Documents” are supposed to address, they allow dictionary maintainers to document the ways disparate vendors version their products.  This provides a mechanism to record the semantics of the version on a per product basis if necessary, so for Cisco IOS we can document what each digit in the version actually means (e.g.  major version, minor version, release, interim build number, train identifier).  This would start off as a largely paper based exercise, but I think the goal is to provide a model where we can actually capture these granular relationships, I think we even mentioned the idea at the last developer days of setting up a working group to model these more complex versioning strategies. 

 

It would be great if we could standardize on one high-level versioning scheme, but until the rest of the IT industry does I think we may lose the ability to capture meaningful information.

 

-Paul

 

From: shanford [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 9:50 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

 

FWIW, standardizing on the ‘.’ character and removing the other_edition proposal from 2.3 will make complex product version schemes like IOS difficult to break down into constituent parts. {e.g. 12.3(8)SXT11a}

We’re not alone, of course. The majority of Hitachi products (e.g. Cosminexus Application server 05-01-/A), and more complex firmware designations like 3Com 4500 series switches like V3.01.00s168p01 could benefit from not standardizing on ‘.’ or doing away with the other_edition capability.

Thanks,
Seth Hanford

On 5/20/10 9:33 AM, "Cheikes, Brant A." <bcheikes@...> wrote:

At this late stage in the preparation of 2.3, I doubt we can break the version field out into multiple parts.  That said, I wonder whether we could define a content-management principle to standardize on, say, the “.” (period) as the separator between each element of a version string.  This is the typical case, though there are probably some outliers.  This might mean deprecating some number of names in which different parts of the version field are delimited with other characters, but that might be doable.  Then we get most of what we need with the single/multi-character wildcards.
 
Re other_edition, I don’t have any good examples and we may well drop it. It was originally tossed in as a lagniappe.
 
/Brant
 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


From: Berkebile, Brenda G [[hidden email]]
Sent: Wednesday, May 19, 2010 9:50 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Brant,

Thanks for the prompt response.  The versioning is complex.  Before I learned of CPE, I had devised a similar practice around software component titles that would meet the needs of our organization and the varying levels of interest in the product data.  I used 3 values to represent the version, Release/Major, Minor, and Fix/Update, which have met the needs of all areas tracking, counting, supporting, recording and purchasing all software components.  There are many right and wrong ways to work with versions, this is just an example of how it worked for our large enterprise.

Please provide the elements that may be represented in the other_edition distinction.

In regard to the distinction between the dollar sign and asterisk, there is significant value in knowing that an element is not known.  I interpret this as the dollar sign indicating that the element was investigated, but not found.  Along the same lines that blank and null can have different meanings in data elements.

Regards,
Brenda



From: Cheikes, Brant A. [[hidden email]]
Sent: Wednesday, May 19, 2010 8:28 AM
To: CPE-DISCUSSION-LIST@...
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon
Brenda,
 
Regarding versioning, it turns out that this is a complex issue that we weren’t able to properly address in 2.3 due to time constraints.  First, it’s not clear what partitioning of version data to standardize on.  We heard suggestions ranging from two (major, minor), to six (major, minor, subminor, build, …). There’s lots of inconsistency in the ways vendors version their products, and where to draw a line between “version” and “update” information (if even such a line should be drawn).  We’ve tried to partially address this in 2.3 by introducing a capability for within-component matching (single and multi-character wildcards) with the thought that this could be an 80% solution.  The need to maintain backward compatibility with 2.2 also limits our flexibility.  I expect that we will be able to provide a much more satisfactory representation of version information once we move on to a 3.0 major release.
 
You’re on the right track re the new edition-related distinctions.  The concept behind sw_edition is that it captures those elements of the product description which relate to how the product is tailored to a particular market or class of end users—“Home”, “Professional”, “Student”, etc. (as you guessed).  The concept behind target_sw is that it captures those elements of the product description which relate to the software computing environment within which the product operates—as you guessed, “for Windows”, “for MacOS”, “for Oracle 9”, etc.  The concept behind target_hw is that it captures those elements of the product description related to the physical computing platform, e.g., “x32”, “x64”, “sparc”, etc.
 
At the Naming level of the specification stack, we are simply introducing these new attributes and giving them informal definitions (as above).  When it comes to managing dictionary content, I imagine that dictionary curators will develop “valid values lists” and refine them over time.  That is, curators will build reusable term lists for the various values of sw_edition, target_sw, and target_hw, rather than just putting in whatever they feel like on a given day.
 
I’m sure you’ve warmed Paul Cichonski’s heart regarding the dollar sign!  He’s leading the Dictionary work and we’re all still trying to come to some consensus re whether or not to make the distinction explicit.
 
Cheers,
/Brant
 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


From: Berkebile, Brenda G [[hidden email]]
Sent: Wednesday, May 19, 2010 9:00 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Please forgive me for coming to the party late.   I have questions relating to the version and editions segments.  The following Formatted String Binding example was provided:
 

cpe-2.3:/a:adobe:acrobat++:9.2:-:*:-:-:x64:-



Wouldn't the release version and minor version be separated to clearly identify all subsequent versions of a release?  As in the example, ':9.2:' would be separated as ':9:2:'  Why wouldn't segmenting the version be handled at the matching level?  Perhaps I missed a previous discussion in this regard or misunderstand.



Please provide content examples that would represent sw_edition, target_sw, other_edition.  Would sw_edition include "Standard", "Professional", et. al.?  Would target_sw refer to the required component that may be indicated as "...for Microsoft SQL"?



I do like the distinction between the "$" and the "*", very useful.



Regards,

Brenda


From: Cheikes, Brant A. [[hidden email]]
Sent: Friday, May 14, 2010 10:12 AM
To: CPE-DISCUSSION-LIST@...
Subject: [CPE-DISCUSSION-LIST] Slides for today's webcon
We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.
 
Cheers,
/Brant
 
Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352





This e-mail, including attachments, may include confidential and/or



proprietary information, and may be used only by the person or entity



to which it is addressed. If the reader of this e-mail is not the intended



recipient or his or her authorized agent, the reader is hereby notified



that any dissemination, distribution or copying of this e-mail is



prohibited. If you have received this e-mail in error, please notify the



sender by replying to this message and delete this e-mail immediately.


This e-mail, including attachments, may include confidential and/or

proprietary information, and may be used only by the person or entity

to which it is addressed. If the reader of this e-mail is not the intended

recipient or his or her authorized agent, the reader is hereby notified

that any dissemination, distribution or copying of this e-mail is

prohibited. If you have received this e-mail in error, please notify the

sender by replying to this message and delete this e-mail immediately.


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
Reply | Threaded
Open this post in threaded view
|

Re: Slides for today's webcon

Paul Cichonski
Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Brenda,

 

This is being proposed as part of the CPE 2.3 Dictionary Spec.  The goal is to have every dictionary either standup their own, or reference a community, decisions document.  For example, when NVD upgrades our CPE dictionary to 2.3 we will provide the accompanying decisions document.

 

-Paul

 

From: Berkebile, Brenda G [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 10:21 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

 

Excellent!  Exactly what I'm looking for.  Where would I find this “Dictionary Content Management/Decisions Documents”?

 


From: Cichonski, Paul [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 9:02 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

I agree with Seth here, the problem we face is that different Vendors/Products version their products according to proprietary methodologies.  This is what the “Dictionary Content Management/Decisions Documents” are supposed to address, they allow dictionary maintainers to document the ways disparate vendors version their products.  This provides a mechanism to record the semantics of the version on a per product basis if necessary, so for Cisco IOS we can document what each digit in the version actually means (e.g.  major version, minor version, release, interim build number, train identifier).  This would start off as a largely paper based exercise, but I think the goal is to provide a model where we can actually capture these granular relationships, I think we even mentioned the idea at the last developer days of setting up a working group to model these more complex versioning strategies. 

 

It would be great if we could standardize on one high-level versioning scheme, but until the rest of the IT industry does I think we may lose the ability to capture meaningful information.

 

-Paul

 

From: shanford [mailto:[hidden email]]
Sent: Thursday, May 20, 2010 9:50 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

 

FWIW, standardizing on the ‘.’ character and removing the other_edition proposal from 2.3 will make complex product version schemes like IOS difficult to break down into constituent parts. {e.g. 12.3(8)SXT11a}

We’re not alone, of course. The majority of Hitachi products (e.g. Cosminexus Application server 05-01-/A), and more complex firmware designations like 3Com 4500 series switches like V3.01.00s168p01 could benefit from not standardizing on ‘.’ or doing away with the other_edition capability.

Thanks,
Seth Hanford

On 5/20/10 9:33 AM, "Cheikes, Brant A." <bcheikes@...> wrote:

At this late stage in the preparation of 2.3, I doubt we can break the version field out into multiple parts.  That said, I wonder whether we could define a content-management principle to standardize on, say, the “.” (period) as the separator between each element of a version string.  This is the typical case, though there are probably some outliers.  This might mean deprecating some number of names in which different parts of the version field are delimited with other characters, but that might be doable.  Then we get most of what we need with the single/multi-character wildcards.
 
Re other_edition, I don’t have any good examples and we may well drop it. It was originally tossed in as a lagniappe.
 
/Brant
 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


From: Berkebile, Brenda G [[hidden email]]
Sent: Wednesday, May 19, 2010 9:50 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Brant,

Thanks for the prompt response.  The versioning is complex.  Before I learned of CPE, I had devised a similar practice around software component titles that would meet the needs of our organization and the varying levels of interest in the product data.  I used 3 values to represent the version, Release/Major, Minor, and Fix/Update, which have met the needs of all areas tracking, counting, supporting, recording and purchasing all software components.  There are many right and wrong ways to work with versions, this is just an example of how it worked for our large enterprise.

Please provide the elements that may be represented in the other_edition distinction.

In regard to the distinction between the dollar sign and asterisk, there is significant value in knowing that an element is not known.  I interpret this as the dollar sign indicating that the element was investigated, but not found.  Along the same lines that blank and null can have different meanings in data elements.

Regards,
Brenda



From: Cheikes, Brant A. [[hidden email]]
Sent: Wednesday, May 19, 2010 8:28 AM
To: CPE-DISCUSSION-LIST@...
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon
Brenda,
 
Regarding versioning, it turns out that this is a complex issue that we weren’t able to properly address in 2.3 due to time constraints.  First, it’s not clear what partitioning of version data to standardize on.  We heard suggestions ranging from two (major, minor), to six (major, minor, subminor, build, …). There’s lots of inconsistency in the ways vendors version their products, and where to draw a line between “version” and “update” information (if even such a line should be drawn).  We’ve tried to partially address this in 2.3 by introducing a capability for within-component matching (single and multi-character wildcards) with the thought that this could be an 80% solution.  The need to maintain backward compatibility with 2.2 also limits our flexibility.  I expect that we will be able to provide a much more satisfactory representation of version information once we move on to a 3.0 major release.
 
You’re on the right track re the new edition-related distinctions.  The concept behind sw_edition is that it captures those elements of the product description which relate to how the product is tailored to a particular market or class of end users—“Home”, “Professional”, “Student”, etc. (as you guessed).  The concept behind target_sw is that it captures those elements of the product description which relate to the software computing environment within which the product operates—as you guessed, “for Windows”, “for MacOS”, “for Oracle 9”, etc.  The concept behind target_hw is that it captures those elements of the product description related to the physical computing platform, e.g., “x32”, “x64”, “sparc”, etc.
 
At the Naming level of the specification stack, we are simply introducing these new attributes and giving them informal definitions (as above).  When it comes to managing dictionary content, I imagine that dictionary curators will develop “valid values lists” and refine them over time.  That is, curators will build reusable term lists for the various values of sw_edition, target_sw, and target_hw, rather than just putting in whatever they feel like on a given day.
 
I’m sure you’ve warmed Paul Cichonski’s heart regarding the dollar sign!  He’s leading the Dictionary work and we’re all still trying to come to some consensus re whether or not to make the distinction explicit.
 
Cheers,
/Brant
 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


From: Berkebile, Brenda G [[hidden email]]
Sent: Wednesday, May 19, 2010 9:00 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Slides for today's webcon

Please forgive me for coming to the party late.   I have questions relating to the version and editions segments.  The following Formatted String Binding example was provided:
 

cpe-2.3:/a:adobe:acrobat++:9.2:-:*:-:-:x64:-



Wouldn't the release version and minor version be separated to clearly identify all subsequent versions of a release?  As in the example, ':9.2:' would be separated as ':9:2:'  Why wouldn't segmenting the version be handled at the matching level?  Perhaps I missed a previous discussion in this regard or misunderstand.



Please provide content examples that would represent sw_edition, target_sw, other_edition.  Would sw_edition include "Standard", "Professional", et. al.?  Would target_sw refer to the required component that may be indicated as "...for Microsoft SQL"?



I do like the distinction between the "$" and the "*", very useful.



Regards,

Brenda


From: Cheikes, Brant A. [[hidden email]]
Sent: Friday, May 14, 2010 10:12 AM
To: CPE-DISCUSSION-LIST@...
Subject: [CPE-DISCUSSION-LIST] Slides for today's webcon
We will be using the attached slide deck to facilitate discussion during today’s CPE webcon.
 
Cheers,
/Brant
 
Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352





This e-mail, including attachments, may include confidential and/or



proprietary information, and may be used only by the person or entity



to which it is addressed. If the reader of this e-mail is not the intended



recipient or his or her authorized agent, the reader is hereby notified



that any dissemination, distribution or copying of this e-mail is



prohibited. If you have received this e-mail in error, please notify the



sender by replying to this message and delete this e-mail immediately.


This e-mail, including attachments, may include confidential and/or

proprietary information, and may be used only by the person or entity

to which it is addressed. If the reader of this e-mail is not the intended

recipient or his or her authorized agent, the reader is hereby notified

that any dissemination, distribution or copying of this e-mail is

prohibited. If you have received this e-mail in error, please notify the

sender by replying to this message and delete this e-mail immediately.


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.