Minutes of July 9 teleconference

[Patrick Curran <Patrick.Curran@Sun.COM>]

Present: Patrick Curran, Stephen Green, Kevin Looney.

There was no quorum for this meeting, but nevertheless we felt it would be useful to discuss various open issues.

We asked Stephen what he thought were the most important issues that required resolution in order to complete the document. His list:

• Weak predicates: respond to Jacques' latest note
• Prescription levels: agreement.needed on whether negation is necessary
• Versioning
• Prior art: add some blurb to each reference

We reviewed the list of open issues and confirmed that there were no other significant issues outstanding. We postponed a review of open Action Items since most members were not present.

We discussed Jacques' note on weak predicates. Patrick argued that this construct is unnecessary. Others seemed to agree. See Patrick's email response.

This led into a brief discussion on the question of specification quality, and whether or not this is in scope. We agreed that there is value in annotating test assertions as ambiguous, contradictory, or difficult to test, and noted that the existing tagging mechanism could be used for this purpose. We agreed that Stephen would add a sentence or two on this subject to the "benefits of test assertions" section but that we would not go very deeply into the matter.

On negative prescription levels (distinguishing between MUST and MUST NOT, for example, rather than simply noting that a requirement is mandatory) we agreed that this is necessary.

We discussed versioning, noting that specs change over time, and therefore that the associated assertion lists will change. Any individual test assertion therefore refers not just to a "specification" but typically to "every version of the specification starting with version x", or to "every version of the specification between x and y". How should this information be encoded? The "specification reference" could of course include a version number, but this might make it more difficult to share test assertions between versions of a spec. (Typically when a new version of a spec is produced the majority of existing assertions remain valid, a small number are changed, and new assertions are added. Starting from scratch with each version, and generating a new assertion list, is not efficient and may be impractical.) We decided to postpone further discussion of this topic until we see Paul's draft on the subject.

We didn't discuss the prior art topic except to note Stephen's concern that he is not best qualified to take this on. We need a new owner for this AI.