4 April 2000

1
Environmental Data Coding Specification (EDCS)
Product Development Group (PDG)

• 4 April 2000
• Initial Meeting
• Argonne National Laboratory
• Dr. R. F. Richbourg
• rrichbou_at_ida.org

2
Who Is Here?
At face to face meetings and teleconferences,
all present PDG members are eligible to vote. A
minimum of a five person quorum is required to
conduct a vote.
Role Call Meeting called to order
3
Agenda

• 0800 - 0815 Introduction
• 0815 - 1130 EDCS Purpose, status, review
• 1130 - 1200 SISO Products Personnel duties,
  product categories, approval process
• 1200 - 1300 Lunch
• 1300 - 1330 - Election SISO process,
  nominations, vote
• 1330 - 1500 EDCS-related products
• 1500 - 1630 Working Session(s)
• 11630 - 1730 Report Out, Next Steps

4
Why Are We Here?
When the SISO Product Nomination has been
approved by the EXCOM, a kickoff meeting is held
to launch the new PDG activity. The kickoff
Meeting shall define basic operating ground
rules, communications channels, and overall
schedule for the tasks to be completed. The PDG
Officers (Chair, Vice Chair, Secretary, DG
Editors, DG Members, Assigned Reviewers) shall
be selected. The PDG shall review the SISO PDG
Handbook and accept of modify the default
procedures. Some modifications require SAC
approval.
5
SISO Operating Principles

• The PDG shall be a world-class team that
  satisfies the needs of the products community.
  To accomplish this goal, it shall conduct itself
  in accordance with the following basic operating
  principles
• Responsiveness and Responsibility - SISO shall be
  responsive to the communities it serves. SISO
  shall be responsible for providing products and
  services that promote interoperability with the
  least possible impact on existing applications.
• Quality - SISO activities and resulting products
  shall reflect technical excellence and the
  highest quality work.

6
SISO Operating Principles

• Discipline - SISO shall exercise due process in
  all activities. Policies and procedures shall be
  publicly available and shall serve as the basis
  for governing the organization and its
  activities.
• Fairness - SISO activities shall provide the
  right of appeal at all levels.
• Openness - SISO activities shall be carried out
  in an open forum where any person has access to
  the process.
• Consensus - SISO decisions shall be based on
  simple majority agreement unless explicitly
  stated otherwise. Votes and ballots may be
  conducted in person, by teleconference, or by
  electronic balloting, as appropriate, and as
  established by the Product Development Group for
  each balloted effort.

7
EDCS Description
8
SISO Products
Reference Products Sources of information that
provide a passive input to models and
simulations. May also be an aid to
research. Include, e.g., reports prepared by
Study Groups, Data Dictionaries, Lexicons and the
SIW Proceedings. Administrative Products
Developed by SISO to guide the operations and
practices of the organization. Examples include
the SISO Vision document and the SISO Policies
and Procedures.
9
SISO Products

• Standards Products Formally approved documents
  that reflect consensus agreements on products,
  practices, or operations, as required, by
  simulation industry applications.
  Interoperability with a SISO Standard shall
  require full compliance to document
  specifications.
• The RPR FOM is a SISO Standard Product.
• Guidance Products Documents that can control the
  development, integration, and use of common
  reference data in some portion of the MS
  community.
• Similar to Standards in that they describe SISO
  Best and Current Practices. A recommended
  development process is an example of a Guidance
  Product.

10
SISO Product Development Process

• 1. Activity Approval (DONE)
• 2. Product Development
• 3. Ballot Product (Not required for Reference
  Administrative Products)
• 4. Product Approval (SAC, CC, EXCOM as
  applicable)
• 5. Distribution and Configuration Management
• 6. Periodic Review

11
Product Development Phase
During this step, the product is developed. This
is typically accomplished by members from the
community who volunteer for the effort. The
volunteers establish a clear understanding of the
product to be developed. In the case of unclear
or ambiguous information, the volunteers contact
the product proponent or the SAC member
designated as the Technical Area Director (TAD)
for the effort to obtain additional information.
The volunteers execute the plan and schedule to
accomplish the product development as established
during the activity approval process.
Modifications must be approved by consensus of
the product development volunteers, the SAC, and
the EXCOM.
12
Development Schedule (1 of 2)

• 07/17/00 Hold second PDG meetings
• Objective includes finalizing product format and
  defining V1.0 endpoint
• Use 7/3 WG8 results
• 07/24/00 Post meeting minutes
• 09/03/00 Resolve comments
• Post to reflectors for review
• 09/19/00 Status outbriefs Fall 00
  SIW SNE/SENS Forums (Joint)
• 10/02/00 Make final resolutions and annotate
  documents as necessary.
• Post to reflectors
• 10/02/00 TAD forwards differences from ISO
  documents to National Standards bodies for
  consideration

• 03/30/00 Announce start up of two distinct
  PDGs (SRM, EDCS) - done at Spring SIW
• Ask for volunteers (30 days for response)
• 05/04/00 Hold PDG kickoff, elect PDG Officers.
  Post Election results and start 10 day recall
  period
• At Argonne National Lab, Illinois coordinated
  with SAM 15
• 05/08/00 Post meeting minutes . Post initial
  WG8 WD documents for review and ask for comments
• 05/19/00 Resolve comments resolve recall of
  elected officers (or forward result for SAC
  approval)
• Post to reflectors for review
• 06/01/00 Make final resolutions and annotate
  documents as necessary
• Post to reflectors
• 06/08/00 TAD forwards differences from ISO
  documents to National Standards bodies for
  consideration

Note that we will not be editing the ISO docs
directly, but rather maintaining recommended
revisions for submittal to National Standards
bodies, e.g. ANSI H3.
13
Development Schedule (2 of 2)

• 10/16/00 Hold third PDG meetings
• Update products to final draft
• 10/23/00 Post meeting minutes
• 11/27/00 Resolve comments
• Expect ISO docs to be in Committee Draft stage
  will need to post to reflectors and adjudicate
  differences with final SISO draft products
• Post to reflectors for review
• 01/02/01 Make final resolutions and annotate
  documents as necessary.
• Post product V1.0 to reflectors.
• 01/02/01 TAD forwards differences from ISO
  documents to National Standards bodies for
  consideration

• 01/09/01 Teleconference
• Vote on release of EDCS V1.0 Product for AR
  Ballot
• Vote on release of SRM V1.0 Product for AR Ballot
• 01/15/01 ? 02/15/01 AR Ballot
• Possible inputs from WG8 CD docs
• 02/19/01 ? 03/22/01 AR Resolution
• 04/02/01 Vote for Community Ballot
• 04/03/01 ? 05/04/01 Community Ballot
• Possible inputs from WG8 CD docs
• 05/07/01 ? 06/06/01 Community Ballot Resolution
• 06/07/00 V1.0 Products

14
PDG Officers

• PDG Chair The PDG Chair manages the PDG
  organization and meetings, reports progress to
  the SAC, and works with the Technical Area
  Director (TAD, a member of the SISO SAC who will
  oversee PDG operations) to ensure that the group
  is responsive to the PDG nomination
• PDG Secretary The Secretary assists the Vice
  Chair and is responsible for meeting minutes,
  consolidating reflector discussions, and posting
  schedules and announcements
• PDG Vice Chair (optional) The Vice Chair assists
  the Chair and acts as the Chair when the Chair is
  not available for PDG meetings or teleconferences
• Note (The Vice Chair should also act for the
  PDG Secretary when the Secretary is not available)

15
PDG Organization

• Drafting Group - This group is responsible for
  evaluating and evolving a draft product
  circulating the product for review responding to
  comments by reviewers and responding to the SAC
  on scope, schedule, and technical issues. DG
  membership normally ranges from five to seven.
  Drafting group membership is assigned by the SAC.
• Assigned Reviewers - This group is responsible
  for concentrated review and comment on all
  products, including interim products. There are
  10 - 20 Assigned Reviewers. The members are
  recommended by the Drafting Group and approved by
  the SAC.
• Volunteer Reviewers - This group is responsible
  for overall review of the product. The Volunteer
  Reviewers review any draft of the product and
  provide comments to the Drafting Group.
  Volunteer Reviewer membership is unlimited in
  size and is open to the MS community and all
  interested parties.

16
The Drafting Group

• DG Editor  The Drafting Group Editor is selected
  from the PDG membership by the PDG Chair and TAD.
  The DG Editor is responsible for developing a
  component based on direction from the PDG. The
  DG Editor assigns specific tasks to DG members,
  collects input, and integrates it into the
  component. The DG Editor reports the efforts of
  the DG to the PDG.
• DG Member  A DG Member provides input in the
  development of the draft Product or Product
  component. The default DG Membership shall be
  the PDG membership. However, this may be
  unworkable. The PDG may develop a narrower
  definition of DG membership, and submit it for
  SAC approval.

Note We will solicit DG Member volunteers and a
DG Editor volunteer the DG Editor will be
considered an elected PDG Officer
17
Lunch
18
The Approval Process
19
Officer Election Process

• Self-Nominations on EDCS PDG Reflector  closed
  30 April 00  3 received
• Self-Nominations at EDCS PDG Meeting (today!)
• PDG members present vote on the candidates for
  Chair, Secretary, Vice Chair (Objections to
  open vote?)
• Any candidate receiving at least 75 of the vote
  is (provisionally) elected
• Election results will be posted to the reflector
  immediately following the meeting, and the 10 day
  "recall period" will be announced (ends 17 May
  2000)

20
Election Recall Electronic Voting

• Unless a sufficient number (10, or more than the
  number of votes received, whichever is less) of
  recall messages are received within the recall
  period, the results will be declared official and
  sent to the SAC for approval
• If no candidate for a particular office gets the
  required number of votes (including the case
  where a quorum is not achieved), or if there is a
  successful recall, an electronic vote for that
  office will be held (18 to 24 May 2000)
• The electronic vote will be conducted by the
  officers that were elected, if any, or by the SRM
  TAD, if any, or by the SNE Forum Chair. Officers
  will be elected by a simple majority of the PDG
  membership (50 1). At the end of the
  electronic voting period (15 days total), the
  results will be announced and sent to the PDG
  Chair for approval.
• Results may be appealed to the SAC

21
Volunteer Nominations
PDG Chair R. Richbourg PDG Vice Chair Dale
Miller PDG Secretary (None) DG SISO Product
that refers to the EDCS as defined by the ISO/IEC
document WG8 N0026 Environmental Data Coding
Specification DG Members R. Richbourg DG
SISO Product from the EDCS API (EDCS Language
Bindings) DG Members (None)
22
Potential EDCS-based SISO Products
Domain Specific Subsets Subsets of the EDCS may
fully describe data in specific functional
domains. These subsets could be developed as
products to be used within the functional domains
during data transfer. At the Spring 00 SIW, the
EO/IR functional domain was described as a
potential application area for this type of
product. Are there other such functional
domains? Are other approaches sufficient for
this purpose (Group definition)?
23
Potential EDCS-based SISO Products
Pre-simulation Mappings The EDCS provides
alternate encoding schemes for some data objects.
As an example, a Lighthouse could be described
by either of the following ECC BC050
(Lighthouse) ECC AL015 (Building) and EAC BFC_
82 (Building Function Code 82 is
Lighthouse) Other ECC and EAC combinations are
also possible. It would be useful to recognize
standard mappings between the EDCS and DFAD
DMAFF FACC DTED / CIB USGS DLG-3. Are there
other useful mappings?
24
Potential EDCS-based SISO Products
Run-time Mappings Similar issues exist when
using the EDCS during run-time. Examples include
mappings between the DIS EBV and the EDCS and, as
a logical extension, EDCS use as part of the RPR
FOM Are there other useful mappings?
25
Potential EDCS-based SISO Products
Attribution Just as alternate ECC or ECC EAC
combinations can describe similar objects, the
are many opportunities to select from different
EAC when describing attribution. Are there
circumstances when a standard set of EAC should
be required? Are there cases when one EAC should
be preferred?
Are there other potential products?