Minutes of September 29th meeting, attached for review.

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

for review,

-jacques

Test Assertions Guidelines (TAG) TC meeting

Event Description:
------------------

Tuesday 2pm (California time), 29 September 2009

Host confcall: Fujitsu
US Toll Free: 877-995-3314
US Toll/International: 210-339-1806
Passcode: 9589308

Agenda: 
-------

1. Admin:
- approval of past minutes.

2. Guidelines document: Follow-up on PR comments.
- review of latest draft (1.0.7) from Stephen:
http://www.oasis-open.org/committees/document.php?document_id=34304
- discuss and/or review:
. making the Guidelines "normative".
. optional Prescription element.
. TA outcomes: where to describe (Currently end of 4.2) 
. conformance statements in Predicate? (see Jacques/Kevin) 
. reference to EARL lge (W3C) 

3. TA markup deliverable:
- sample "widget":
http://www.oasis-open.org/committees/document.php?document_id=34298
- UBL use case:
http://www.oasis-open.org/committees/document.php?document_id=34299
- The PDF doc:
http://www.oasis-open.org/committees/document.php?document_id=34295
- draft schema:
http://www.oasis-open.org/committees/document.php?document_id=34297



Participants:
------------

Stephen Green, (Document Engineering Services)

Jacques Durand, (Fujitsu)

Kevin Looney  (Sun Microsystems)

Dennis Hamilton (individual)

Paul Rank (Sun)

Tim Boland (NIST)


Excused:



Action Items:
-------------

AI1-Sep-29-09: Stephen to use the OASIS template for specs.

AI1-Sep-15-09: Kevin to review the EARL doc and make recommendation.



Minutes: 
-------


'''1. Admin:'''

- approval of past minutes:
- September 1st: approved.


'''2. Guidelines document: Follow-up on PR comments.'''
- review of latest draft (1.0.7) from Stephen:
http://www.oasis-open.org/committees/document.php?document_id=34304
- discuss and/or review:
. making the Guidelines "normative".
. optional Prescription element.
. TA outcomes: where to describe (Currently end of 4.2) 
. conformance statements in Predicate? (see Jacques/Kevin) 
. reference to EARL lge (W3C) 

JD: In 1.0.7 guidelines: Appendix B: isn't it redundant with Fig 4, which itself is 
restating what Fig 3 is saying just in a more "model-like" style?
DH: Well appendix B is saying much more, adds TA set and "shared".
SG: redundancy not necessarily bad. Fig 4 adds cardinalities to Fig 3, more appropriate
for a normative doc.
JD: then shouldn't we describe the whole model (with TA set) in the main body of the
guidelines, rather than just a quick shot at it in Appendix?

DH: Section 5 (conf clause) is too strong: should be focused on COnformance targets, can we
identify some? This is not a spec of a process, but more about what is a conforming
test assertions document. So the COnf clause needs be more flexible.
JD: we may not need to separate "normative" section from "non-normative" section.
Normative does not mean mandatory. Means something we can conform to, and measure so.
Several (optional) advanced features are as normative as the core part.
SG: made changes to comply with ISO normative language rather than RFC.
DH: ISO specs can't use "MUST". And "SHOULD" does not have same sense in ISO and RFC.
ISO: recommended (preferred). IETF: needs a justification to NOT do it.
JD: we need to be consistent on our normative lge (ISO? RFC?) 
- we also need to finalise the meaning of "preferred" w/r to ISO / RFC: do we need
more specific labels / code names? The Glossary needs to address that.
DH: "implementation-defined" is different from "implementation-dependent":
- implementation-defined: left to the implementation to decide, but it MUST specify the
behavior.
- implementation-dependent: the implementation does what it wants.

KL: EARL concenrs different domains of application. Tries to encode test results + behavior.
There is a notion of assertions, not detailed. EARL describes the code + test outcomes.
KL: to add an EARL entry to the References list in guidelines.


'''3. TA markup deliverable:'''
- sample "widget":
http://www.oasis-open.org/committees/document.php?document_id=34298
- UBL use case:
http://www.oasis-open.org/committees/document.php?document_id=34299
- The PDF doc:
http://www.oasis-open.org/committees/document.php?document_id=34295
- draft schema:
http://www.oasis-open.org/committees/document.php?document_id=34297


- SG: need XML schema: inside the spec body or in Appendix?
- JD: I'd say in Appendix, because its a big chunk of rather unreadable script.
Need to find a more reader-friendly notation for main body of the mark-up spec.
- DH: we need to deal with two sources of conformance: (a) schema, (b) main body
of markup spec + the underlyng model.
- SG: Appendices are not normative in OASIS.
- SG: we can also link to the schema as a separate file. Several specs do that.
- DH: W3C uses the "infoset model", an abstraction orthogonal to XML.
- JD: W3C in WSDL spec and SOAP specs, use of more intuitive notation for schemas:
regexp style (?, *, +,...)
- SG: we also need to stick to OASIS templates.
- DH: but also need to position for ISO.
- SG: as long as teh schema is in a normative section, we are fine.