Minutes Nov 10, for review

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

 

Test Assertions Guidelines (TAG) TC meeting

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

Tuesday 2pm (California time), 10 November 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.
- deliverables packaging options, standard track.

2. Guidelines document: 
- review of latest candidate version 1.0.8.4.
http://www.oasis-open.org/committees/document.php?document_id=34916

3. TA markup deliverable:
- latest: 0.9.3 "markup language"
http://www.oasis-open.org/committees/document.php?document_id=35051
- discussion points: 
o the "shared" markup and semantics.
o referencing external TAs: alternative mechanisms? (XPointer, URIs) o test assertion set.


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

Stephen Green, (Document Engineering Services)

Kevin Looney  (Sun Microsystems)

Jacques Durand, (Fujitsu)

Dennis Hamilton (individual)

Tim Boland (NIST)


Excused:

Paul Rank (Sun)



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


Minutes: 
-------

'''1. Admin:'''

- approval of past minutes: October 27: approved.
- Action Items:
- DH: did follow-up with Mary if we need the diffs marked for the 
2nd public review, even if we have a substantially different document.(late on his AI).
It looks like we may want to consider a new PR submission as a brand new one anyway.
- JD: proposed rewording of the conf clause to handle both
TA representations (for the TA model) and actual TA instances. For review.
- SG: revisited the <shared> structure, handling its conflict semantics in a more
finegrained way (using new attribute) 


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

- option #0 (see JD email 10/28) : need to check with PAS process from OASIS (JTC1)
- DH: minimum requirements to check: Conf clause, normative terms. Has to be edited
as for ISO track. Examples handling: raise red flag if the narrative is too dependent
on examples.
- KL: Guidelines doc is useful as a working doc, makes sense to be example-centric.
- TB: need to be able to conform to the TA model without conforming to the mark-up.
- JD: still need to craft a conf clause to the model.
- DH: the Guidelines wording depends on the TA Model.
- DH: examples are: RDFa spec referes to RDF spec. A key issue is: can't have  a dependency 
of normative text on examples. Separating docs is cleaner. Approach #2 seems OK.
- JD: so it looks like we still want to separate TA model from TA markup even in #2.
- SG: 3 docs option is not a problem: 
(1) Guidelines would just be committee spec, refer to TA model.
(2) TA model, normative, would go standard.
(3) TA markup, normative, refers to TA model, would go standard.
- KL: OK with this. But concerned about requirements for ISO format. OK to go with 
OASIS specific format.
- DH: need to keep TA model and TA markup separate.
- SG: MOTION: move to split deliverables in 3 documents above, 2 of them intended as 
normative for standard track, the other being just the Guidelines, and informative doc.
- DH: second teh motion.
- unanimously approved.
- JD: OK to have some overlap between Model and Guidelines, especially in intro part.
But some diagrams in Guidelines don't need be in Model.


'''3. TA markup deliverable: latest: 0.9.3 '''

- SG: need a target scheme, ability to refer to external resource. 
Do we need two attributes: (a) URL scheme, (b)category name.
- JD: yes for category: allows to indicate an abstract category identifier (a class name, 
a type name...) while the element value may be available to identify an instance set 
(e.g. by XPath). So not the same thing. But indeed if the formal category is itself
defined more completely outside (e.g. ontology), URL is useful.
- JD: "Interpretation" needs be defined and explained in teh TA Model.
- DH: Example of ODF: Conformance language in ODF is poor: the profiling is done in the markup.
- DH: do we need both Norm Source + Interpretation, or just the latter?
- It appears that Norm Source should be what the predicate is really expressing,
and Interpretation if any should then be referred by NormSource, not the opposite.
- SG: Interpretation is both in the NormSource, and in the markup.
- SG: comment element added for Predicate and other individual elements.
- JD: can't we just deal with <desccription> element at top level, which can be as
detailed as we want? Would provide a synthetic explanation elee\ment for the entire TA.
- SG, DH: Description element is OK.