Minutes
ATML Meeting #8
Oct 21st-23rd 2003
Agenda
Revised ATML Meeting 08 Agenda - Reply | New Thread
Posted: 10-Oct-03 11:37 AM by Steve Wegener
Tentative Dates: October 21st-23rd
In San Diego (BAE - Thanks Ron!)
· Day One
· 9:00 Introductions - Sign-in sheet
· 9:10 Minutes and Matters Arising
· 9:20 Review ValueType & Purpose a Vote
§ If approved post on www.atml.org
· 12:00 Lunch
· 1:00 Review the ATML Document Matrix
· 4:30 Wrap Up
· Day Two
· 9:00 Review the Standards Application Matrix
§ Survey group presentation
· 10:00 Review Previous Day
§ Impact of ValueType
§ Suggest creation of a LimitType
§ Suggest creation of a UnitType
· 10:30 Review TRML Document
· 12:00 Lunch
· 1:00 Continue TRML Effort
· 4:30 Wrap Up
· Day Three
· 8:30 Review Progress and Issues
· 9:30 Assign Actions
· 9:45 Schedule Next Meeting
· 10:00 Discuss Agenda for Next Meeting
· 11:00 Wrap Up
Attendees
Chris Gorringe - Racal Instruments
Richard Chaffin - USMC
Steve O’Donnell - Lockheed Martin
Phil Williams - Mindready Solutions
Les Orlidge - AAI
Bob McGarvey - AAI
Stephen Osella - National Instruments
Rob Powell - eTesters
John Ralph - AeroFlex(ish)
Teresa Lopez - Teradyne
Jeff Hulett - Vektrek
Rengan Rajendran - Vektrek
Ion Neag - TYX
Bill Mercer - SSAI
Ronald C Jalley Support System Assic
Ron Taylor - BAE Systems
Tim Davis - Navair Depot Jacksonville
Matt Cornish - Racal Instruments
Steve Wegener - Boeing
Thomas Gaudette - The Mathworks
Bob Fox - NavAir
Roadmap
The roadmap was put up on and schedule dates to be reviewed during the meeting.
Team Members
Status
Working Group
Team Leader
ATML
Bob Fox
2
TRML
John Ralph
ISML
Teresa Lopes
TPSML
Tim Davis
Teresa Lopes
Ion Neag
Chris Gorringe
Rob Powell
Tim Davis
Ion Neag
Richard Chaffin
Ron Taylor
Teresa Lopes
Lockheed Martin
Tim Davis
Ion Neag
Rob Powell
Joe Muller
Steve Wegener
Richard Chaffin
Draft Oct 24, 2003
Tim Davis
TCML
Tim Davis
Richard Chaffin
Steve Wegener
UDML
Steve Wegener
Tim Davis
Joe Stanco
Ron Taylor
Chris Gorringe
Richard Chaffin
Lockheed Martin
Draft Feb 2004
4
TPML
Steve Wegener
TSML
Rob Powell
Tim Davis
Joe Stanco
Ron Taylor
Chris Gorringe
Richard Chaffin
Matt Cornish
Lockheed Martin
Tim Davis
Ron Taylor
John Ralph
Rob Powell
Draft Feb 2004
Tim Davis
Bill Birurakis
Teresa Lopes
Chris Gorringe
Matt Cornish
Ion Neag
Lockheed Martin
Tim Davis
Teresa Lopes
Rob Powell
Draft Jan 2004
Aim for Candidate
May 2004
Tim Davis
Rob Powell
Steve Wegener
Draft Oct 24, 2003
Draft Feb 2004
IAML
Rob Powell
3
DML
Steve O’Donnell
Steve Wegner
Assembly
Steve Wegener
1
Value & Limit
Ion Neag & John Ralph
Dooooooomed
Value Type
Strings have a constraint of not allowing quotes(“,’) or <> symbols and will need to be
ampersand quoted or changed to use CDATA format.
Cost/benefits analysis for ValueType
Like the idea of having CDATA sting for make value sub element
Features to be changed
 Need to support composite units
 Support letters (Unit Symbols) not words (Dimension Names)
 Look to have units as a single Units attribute with its own type based on xs:string
1) Leave as it is (7)
2) Change to Int and double (0)
3) Change to Int & double and add extra types (3.5)
Array
The Array’s name ‘SparseArray’to becomes ‘IndexedArray’ because sparse is a use case
not a description of the type.
The <Array> name to represent a collection or group of items. <Collection> or <List>
<Collection> and chosen (7:4)
Use of an ID reference name to a Datum element is not wanted and should belong the
higher element that has the ValueType.
Limit Type
Replace Notch and Range with a single term and additional attribute
Have the comparison with the value limit (GE, GT, LT, and LE) and bound to the limit
value.
Because UL & LL may be absolute and relative., when relative can not only detect that
the UL is greater than LL, relative values for UL, LL are absolute
Remove optional Nominal
UL & LL should be optional
Add Limit Type to have Nominal, UL and LL
UL and LL should be called Limit1 and limit2, why not Limit and list
John should split comparator type off line.
Use of the LimitType is to cover most of the strategy and identify limitations.
LimitType -------Nominal
|---Limits
Standard and Schedule
Recommended three levers for working documents
1. Draft – Draft (many updates)
2. Candidate – Working Draft (minor revisions)
3. Recommendations – Final Draft (fixed revisions)
Have different phases of release for each document.
When a document becomes candidate the document is put on the ATML.org website.
Candidate is intended for internal evaluation only, just some informal document that can
not be carried with the schema. To be a candidate, there must be an informal written
specification that describes the semantics and have every element must have the
annotations filled out, and include all the major examples covering the use cases in the
requirement specification. There is only ever one candidate (the one on the website),
prior to becoming a recommendation with a version.
Recommendation would have standard level documentation associated with the schema.
Bob to define the format and minimum requirement for a candidate release
Action 8-1 Bob to sort out
Need to revisit the Style guide and draft what the ATML style guide will be.
Possible XML Best Practices website.
Action 8-2 Ron Taylor to co-ordinate
Action 8-3 Steve O’Donnell to report back what LIMS are doing
Action 8-4 Tim search out previous guides
Standards Use
The discussion centered on the questions
 How to use the standards that are out there?
 Which standards should be followed for what areas?
Signal Statements
Signal Statements probably represented by three levels
 Standard signal definition (P1641)
 Extendable signal based on standard signals
 Totally open parameter based system
P1641
For signal statements representing the 90% of testing performed this is possibly a good
way to go.
Diagnostics
AI-ESTATE
Is this a candidate for DML (DiagML) group?
Way Forward
It is up to each group to consider the appropriate standards and search out a ‘specialist’
that can best describe the overlap between the group and the standard.
Update the Standard List that identifies the possible standards and the areas or groups
they cover
Action 8.5 Ron Taylor
Units, Value and Limit Type
What are the common types? If all the common types go into one specification the
common types will need to be the same level.
Common types will maintain their own identity in the initial drafts of the ATML release.
May need to consider common types being developed in little pieces prior to combining
them into a single specification so that common specification are not constantly being
changed.
Units & Physical
Two alternative Units scenarios where shown (See Units.ppt)
1. MathML
2. Signal & Test Definition (P1641)
For STD the concept of Physical is
 Qualifier <Pk, pk_pk, trms>
 Quantity e.g. 10mV 123MHz
 errlmt e.g. +- 4%
 range e.g. range 10V to 45V
ValueType
Change complex type to refer to decimal for real and imaginary rather than xs:double.
Action 8.6 Ion Neag
Limit Type
A Limit type is a structure that holds the complete limit information for describing a
complete test space for numeric comparisons. A limit type hold an individual pass fail
criteria that can be used to indicate that a test value has passed or failed
After a brief discussion LimitType (LimitType5.xsd) was concluded to best suit the
<LimitType> … <Expected>
|- <Limit>
|- <LimitPair>
TRML
Some of the material discussed and documented in the last minutes has not been
transferred into the document.
The use of reference is an example of schema extension, For all extensions extensibility
shall be defined in one of two ways
1. any namespace
2. Abstract data type extensions
TRML will use this extensibility mechanism.
Check TRML against Minutes#7 actions to ensure all items have been included
Action 8.7 John Ralph
Process
When we need to change a Schema (.xsd) we need to capture the changes and document
the changes in the minutes.
AoB
Post LMIS use cases on the eTesters Web site.
Action 8.8 Chris Gorringe
Concentrate on interface standards and work back up from.
Where we need to apply enough data for the other items to fulfil
1) TRML
2) DML
3) TPML
Need to get sorted
 Indictment (10) (Steve Wegner)
 UUTData (5) (John Ralph)
 Components (See Indictment)
 Signals
 Resources
 Repair Actions
 Works Orders
 Work Items
 Measurement Data (bit or test failures) pieces or TRML
How can we have a candidate when it call upon another schema is not a candidate.
The initial thought was not complete scope and may not include all use cases. (See
Action 8.4)
ATML Working Group
Aim is to gather the complete ATML working documents as the definatiev ATML
description and set of documents
The current set of dormant ATML documentation contains




ATML Common Component
ATML Style Guide
ATML Handbook
ATMl Requirement & Framework

Schemas
o ValueType.xsd v0.11
o LimitType.xsd v0.5
o TestResults.xsd
For the future all draft versions for non release should initiate with a ‘0 ‘
For Candidate Bob to report back on version items
Action 8-ATML-1 Bob Fox
To approach the IEEESCC20 and IVI groups to identify the pro and cons of aligning the
ATML imitative with those various groups
Action 8-ATML-2 Bob Fox (SCC20)
Action 8-ATML-3 Jeff Hulett (IVI)
Future documentation to be maintained
1. ATML Document (Chris) – End Nov
Mission Statement (2 sentence)
Scope
System Framework
Schedule
List of Documents with synposis
Chairman of each Document
2. Operating Procedures (Bob) Nov
Process for Versioning
3. Style Guide (Teresa) Nov 21st
4. Use Cases Requirement (Jeff Hulett) - Jan Meeting
5. Survey Document (Ron Taylor)
7. Common Components (Steve Wagner)
8. Template Documentation for Schemas (Tesesa) Jan Meeting
9. Schemas (Working Groups)
10. Action/Issues Spread Sheet (Chris)
System Framework architecture to review for rest of documents.
Action 8-ATML-4 Chris Gorringe
Actions will be separated into an Action list groups by working group.
Action 8-ATML-4 Chris Gorringe
Working group issues will be collected by the Working group chair and consolidated by
the ATML secretary in to a master issue log.
Action 8-ATML-4 Chris Gorringe + Group Chairmen
Provide SMART TPS use cases for DML
Action 8-ATML-5 Steve Wegner
Use Cases need to be broken down in to identify the impact on individual working
groups, and schemas. Responsibility falls to the groups to show that the requirements are
met.
Action 8-ATML-6 Jeff Hulett
Common components are currently individual files where the document hold list of the
common types.
Action 8-ATML-7 Steve Wagner
Consider the document style and come up with a common format for the next meeting
Action 8-ATML-8 Chris Gorringe
Date Of next Meeting
Proposed meeting date LMIS 20th -22nd January 2004.
Wednesday 29th October 10:00 (EST) Ongoing Wednesday
Action 8-10 Bob Fox
Action List
Reviewed ATML Requirements Documents
 Goals
 Use Cases
To ensure they still match the group’s collective needs
Action 7-0 All - Ongoing
Talk to BillB over why he wants instrument setup descriptions and expecting from
ATML
Action 7-1 Bob Fox - Ongoing
Update a roadmap showing objectives and dates schedule of completed
Action 7-2 Bob Fox - Completed
Within the ATML a test must have a unique id (GUID) that identifies the test uniquely.
Need to maintain a unique test reference as a string
Action 7.3 John Ralph - Completed
Review the references to see if inline is more appropriate. for
 UUTRef
UUTData
 StationRef
TestStation
 TestProgramRef
TestPrograms
Reference: types shall be created to be complex instance types for all significant objects
in the ATML
Action 7.4 John Ralph - Complete
Remove TestRun ReferenceType element because documentation would not track the
measurement result
Action 7.5 John Ralph - Complete
Recall Mil Standard 1519 as TRD document for input into TRDML complex type
Action 7.6 Ron Taylor - Completed
Each chairperson to provide ½ page description for the scope and mission statement for
their assigned sub-schemas.
Action 7.7 All - Ongoing
Install WebEx on team machines prior to WebEx meetings
Action 7.8 All - Complete
Put up all presentation to web site.
Action 7-9 Chris - Complete
Clean up eTesters Web site and get rid of acronyms move projects over to root element
name
Action 7-10 Bob Fox - OnGoing
Bob to define the format and minimum requirement for a candidate release
Action 8-1 Bob to sort out
Need to revisit the Style guide and draft what the ATML style guide will be.
Possible XML Best Practices website.
Action 8-2 Ron Taylor to co-ordinate
Action 8-3 Steve O’Donnell to report back what LIMS are doing
Action 8-4 Tim search out previous guides
Update the Standard List that identifies the possible standards and the areas or groups
they cover
Action 8.5 Ron Taylor
Change complex type to refer to decimal for real and imaginary rather than xs:double.
Action 8.6 Ion Neag
Check TRML against Minutes#7 actions to ensure all items have been included
Action 8.7 John Ralph - Completed
Post LMIS use cases on the eTesters Web site.
Action 8.8 Chris Gorringe
Investigate and report NavAir can use the access to IEEE documents for the ATML
groups benefit.
Action 8.9 Tim Davis
For Candidate Bob to report back on version items
Action 8-ATML-1 Bob Fox
To approach the IEEESCC20 and IVI groups to identify the pro and cons of aligning the
ATML imitative with those various groups
Action 8-ATML-2 Bob Fox (SCC20)
Action 8-ATML-3 Jeff Hulett (IVI)
System Framework architecture to review for rest of documents.
Action 8-ATML-4 Chris Gorringe
Actions will be separated into an Action list groups by working group.
Action 8-ATML-4 Chris Gorringe
Working group issues will be collected by the Working group chair and consolidated by
the ATML secretary in to a master issue log.
Action 8-ATML-4 Chris Gorringe + Group Chairmen
Provide SMART TPS use cases for DML
Action 8-ATML-5 Steve Wegner
Use Cases need to be broken down in to identify the impact on individual working
groups, and schemas. Responsibility falls to the groups to show that the requirements are
met.
Action 8-ATML-6 Jeff Hulett
Common components are currently individual files where the document hold list of the
common types.
Action 8-ATML-7 Steve Wagner
Consider the document style and come up with a common format for the next meeting
Action 8-ATML-8 Chris Gorringe