OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Notes from meeting today, next Session A meeting May 14th !!


We were not quorate this morning: Tim B., Stephen, Jacques. But some interseting notes below:
 
Trying to end the disruptive streak of "mis-scheduled" meetings since our F2F:
I will reschedule a session A meeting next Wednesday May 14, at 10amPT.
 
Notes from this informal meeting:
 
1- review of Stephen latest draft (0.92, see his email 4/29)
 
- still issue with the use of "test metadata" as a substitute to "test case". Test metadata as defined in:
 http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/
seems to define a terminology / model for testing. Some of its concepts clearly map to ours (e.g. specRef) or have some relationship (precondition, grouping...). So this is not the same thing as the executable unit inside a test suite that many call a "test case".
It appears that "test metadata" means different things also to different groups (even if the defs overlap).
To be resolved.
 
- reviewed the new inserts on "variables".  Still needs work. The examples are not quite convincing in terms of the value added. Normally a pre-requisite should make an explicit statement on some target, not just say: 'GEO-POLITICAL-LOCATION = 'DK', unless we have defined indeed something like a "context" to a test that can be modeled using variables. So we may need to start by introducing this notion of "context". Also: because this variable is about "geopolitical location of use of the widget", one could make the case that what we really want in the prerequisite is a predicate making use of a function on the widget: geopoliticalLocation(widget) = 'DK'.) So we need a better example. 
 
- the notion of "header" to a group of TAs, might need more explicit exposure if not modeling in the guideline. The "test assertions group" header is where implicit TA components may be defined,  where inherited material is, where some variables (some context?) might be defined, serving to parameterize the group of TAs.
 
- Scope of TAs: theambition of the Guideline is to cover TAs that are not limited to software targets. The "widget" examples do a good job at this. But the notions of test case and test metadata seem to be defined in a more restrictive way (in software terms). Need to be clear as what is our scope...
 
- section on grouping (3.5.2): should not introduce a prefix notation tag:<name>" for tag names, that will later on clash with the TAG namespace.
 
2. Discussion of a potentially large user of TAG methodology and mark-up: UBL users (Stephen). Some people are expecting our mark-up... Jacques to consolidate material we have so far (XSD from Serm, and also an update from Jacques based on WS-I experience).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]