Minutes October 27, 2009, for review

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

 

Test Assertions Guidelines (TAG) TC meeting

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

Tuesday 2pm (California time), 27 October 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: 
- review of latest candidate version 1.0.8.3.
- ready to approve?

3. TA markup deliverable:
- review of latest uploads from Stephen.



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

Stephen Green, (Document Engineering Services)

Paul Rank (Sun)

Jacques Durand, (Fujitsu)

Dennis Hamilton (individual)

Tim Boland (NIST)


Excused:

Kevin Looney  (Sun Microsystems)



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

AI-Oct27-1: [Dennis] to check with Mary if we need the diffs marked for the 
2nd public review, even if we have a substantially different document.

AI-Oct27-2: [Jacques] to see how we can reword the conf clause to handle both
TA representations (for the TA model) and actual TA instances.

AI-Oct27-3: [All] Identify the Best Practices we could highlight in the Guideline doc.

AI-Oct27-4: [Stephen] Revisit the "shared" structure and semantics in the mark-up.

Minutes: 
-------

'''1. Admin:'''

- approval of past minutes: October 13: approved.
- PR for a bundle Guidelines + markup? Would be 60 days.
- DH: OK with that: makes it easier to proceed the package later as ISO standard.
- JD: for a second PR we may have to show the diffs with the previous PR docs.
- DH: to check with Mary if we need the diffs marked for the 
2nd public review, even if we have a substantially different document.
- DH: we should use JIRA for defect tracking. http://www.atlassian.com/software/jira/tour/
- DH: if we plan for ISO, we should put the examples in appendix because they are
by nature not normative. At the very least, shold be in "boxes" quite distinct from
main text.
- SG: we already have them summarized in appendix. We have made sure that our examples
do not introduce any new material.
- JD: it seems hard to dissociate the examples from the main text: the main text is 
organized around them, in the spirit of a guidelines document.
- DH: ISO generally accepts a first submission in their original format, but subsequent
updates will not do.


'''2. Guidelines document: Follow-up on latst version.'''

- review of latest candidate version 1.0.8.3.
- ready to approve?

- DH: need to be sure about our conformance target (for conf clause): it looks like
TA documents are our conmformance target.
- JD: it looks like we actually have two levels of conformance to our TA model as
defined in the Guidelines: (1) a TA representation (e.g. mark-up) may be conforming,
(2) a TA instance (expressed either as an abstract notation as in our examples, or as
instance of a markup). Both should be our target for conformance, so the conf clause
should talk about both after all. 
- SG: Probably we need also to talk about TA sets in the conf clause? Also has
a problem with point #4 of Jacques proposal for conf clause (comments in email 10/26)
- We need to identify what are the best practices we have intoduced all over
especially in section 4. Can we isolate them and highlight them?
- DH: example of ODF1.2: there are 3 conformance categories:
(a) static documents, (b) consumer , (c) producer. The OIC TC is also profiling.
The spec can be seen as specifying a behavior, for a processor.

'''3. TA markup deliverable:'''

- review of latest uploads from Stephen.

- JD: overall well advanced document. Need a bit more structure to clearly
distinguish TA instance, from TA sets, and maybe from TA refs.
- JD: "shared" structure looks a bit awkward, as the actual elements are burried
inside containers that advertise how the compose or inherit with the individual TAs.
- SG: should we make "shared" extensible? We could have default rules for
composition, e.g. for "shared" Prerequisites with compose as AND with the TA prereqs.
- SG: concerned that several containers for each flavor of composition / inheritance would 
be too complicated. We cannot probably provide for exhaustive coverage of all cases.
- An option: have possibly several <shared> containers, but tag them with an attribute
 that advertise how its (shared) elements compose with individual TAs if conflict.