Minutes Nov 24

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

For review.

 

-jacques

Test Assertions Guidelines (TAG) TC meeting

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

Tuesday 2pm (California time), 24 November 2009

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

Agenda: 
-------

1- Guidelines split:
- review new non-normative version Guidelines (1.0.8.7)
http://www.oasis-open.org/committees/document.php?document_id=35225
- review new TA model doc:
http://www.oasis-open.org/committees/document.php?document_id=35226

2- Administration:
- minutes Nov 10
- roadmap and next steps with the 3 deliverables

3- markup design (v0.9.7):
http://www.oasis-open.org/committees/document.php?document_id=35212
- extensible codelists / enum
- use of QNamed values1. Administration and Roadmap
- conformance clause


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

Stephen Green, (Document Engineering Services)

Jacques Durand, (Fujitsu)

Dennis Hamilton (individual)

Tim Boland (NIST)


Excused:

Paul Rank (Sun)

Kevin Looney  (Sun Microsystems)



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

AI1-Nov24: [jacques] check with OASIS status of Informational docs. 
Editorial related issues.

AI2-Nov24: [Dennis] to work on a model representation/notation proposal.


Minutes: 
-------


'''1. Guidelines split.'''

SG: Produced new non-normative guidelines based on previous comments, 
removed formal diagrams. 
SG: Should we keep the examples consolidation currently in Appendix in guidelines?
Or wrap them up in markup put them in Markup doc (using markeup)
JD: these examples repeats in Appendix have little added value if non marked-up
SG: marked-up Samples (currently in Markup appendix) are using simple markup, 
so easy to move them in the Guideline doc as markup samples. 
The Guidelines is supposed to also refer to the Markup doc (i.e. be a guidelines also for the markup).
DH: Appendix are not normative, so should not have normative dependencies. 
Currently TOC excludes Appendices. 
- so maybe the marked-up samples should go in Guidelines.

TA Model:
SG: Object-Oriented appears best way to represent abstract model.
We can generate UML afterwards. Then XML from UML (schema in UML is well understood)
JD: How about just UML as the ref representation for our model?
JD: but need be careful that UML-to-XML generation tools must produce our markup...
Will they?
SG: UML not best way to represent our model. Some issues, e.g. UML has to distinguish:
(a) attributes (as datatypes)
(b) associations (as yielding "classes")
That causes Problems e.g. for normativeSource, listed both as attribute and association
because complex type. So we can't generate good XML from this.
So UML in Appendix may be OK but not as prime rep.
SG: In UBL, we moved the UML diags in appendix (not authoritative)
UML not meant to be definitive / normative (not suitable for formal spec).
DH: Not sure we want to emphasize O.O. paradigm for our model. It may also be seen
as Entity-Relationship data model. Warning: it is NOT a programming language notation!
SG: if we do not want to emphasize O.O. then we should not use UML as prime rep.
Just for illustration.
DH: ER Nomenclature may be best. Could use both ER + UML. 
JD: does ER handle complex attributes? Seems to have same issue attribute vs Relationship?
DH: Model notation: can we replace "class" ?
DH: Attribute + associations: need explain these terms.
SG: Notation Translates well to CCTS (Core Components)
DH: Core Componentsdo not lock themselves in a Prog Language notation, so good.
DH: You could just show the relationships, not the itnernal attributes in your diags.
JD: still favor that we use UML somewhere in our model - a popular notation.
DH: will work on a model rep proposal.


'''2. Admin:'''

- approval of past minutes: November 10: approved.
- DH: For public review: two bundles? (Model+Markup) (Guidelines)
- DH: Normally, users want to review Model+Markup, then Guidelines.
- JD: But they are still a complete package, so not sure we want to stage the PRs:
people may want to have all together to go back and forth and check overall consistency.
- Is the Guidelines just a "diff" review? (e.g. shorter) Probably not:
The Model+Markup need anyway 60 days review, so it may be good to align the Guidelines
review to that as well. If yes,
- Hopefully  can position position new Guidelines as an entirely new review (no diffs
necessary). to check with staff. 



'''3. TA markup design: '''

JD: The new markup doc should now refer to the TA Model doc for all its semantics.
SG: Moved material from previous TA markup to TA Model.
But a problem is: must be understandable as a standalone doc !
So some careful redundancy may be needed.