Standards Telecon - PDS Version ID/Local Data Dictionary - 6/11/2003

Standards Telecon, 11 June 2003

9:03 Start

Attendees
C.Acton         T.Brown         L.Hall          L.Huber
S.Hughes        S.Joy           R.Joyner        T.King
A.Raugh         B.Semenov       S.Slavney       R.Simpson
B.Sword

Pre-meeting: Laverne mentions that tech group will have to plan their
tech session if they want want with the next MC.  T.Brown runs down plan
to hold half-day summary session for reporting and maybe discuss one 
or two specific topics.

Updated LDD SCR:
  No comments on changes made since last week.  T.Brown calls for vote
  of those present for sending on to MC. 
  
  NAIF  - Abstain
  Atmos - Yes
  PPI   - Yes
  Ron   - Yes     (as System Engineer)
  SBN   - No
  Betty - Abstain (as CN)
  GEO   - Yes
  
  T.Brown notes we don't have a quorum of nodes represented as yet. Final
  tally will wait until end of meeting.
  
Version ID Draft SCR:
  Lead will be Joyner, not Raugh.
  
  Ron runs through Dick Simpson's emailed comments-
    1. Need criteria and procedure.  Ron notes that the SCR contains an
       outline for this.
       
    2. Dick notes that the PDS_VERSION_ID should correspond to design
       version, not production version. Ron agrees, adding implication
       that the PDS_VERSION_ID must be approved by PDS engineer as part
       design process.  Ron suggests replacing "produced" with "designed
       and approved" throughout the SCR.
       
    3. Fractional versions are not fully addressed. Ron says this is 
       inherently accounted for in the process of getting approval of
       PDS_VERSION_ID value.  Steve H. notes that this is more an
       issue of how the standards are versioned - that PDS_VERSION_ID
       must merely reflect the standards level.
       
       Lyle wants to be able to continue to use "PDS3" in labels as long
       as they are compliant with the older standards.  This prompted a
       general discussion about whether new labels designed after this 
       change can continue to use the generic "PDS3" level, or will be
       forced to use the specific standard level.  No convergence.
       
       Todd asks how this relates to the DD version. Ron notes that the 
       SR version is in the DD. This does not define a unique DD, however,
       since the DD changes much more rapidly.  Steve H. wonders if a DD
       identifier is also necessary in labels. He notes that the 
       PDS_VERSION_ID is both a syntactical and semantic indicator. 
       Ron notes that with local DDs, the DD file will be created and
       delivered with the data.
       
       Todd notes that electronic distribution will defeat this solution
       because the physical association will not necesarily be preserved.
       
  Todd mentions the Impact statement, and whether it reflects the true 
  impact of having changing PDS_VERSION_ID numbers.  Boris re-iterates 
  his desire to continue to be able to produce "PDS3" labels indefinitely.
  
  Steve H. suggests the SCR be re-written to specifically allow this, and
  to provide a specific definition of PDS3.  Steve H. also suggests that
  the SCR also explicitly NOT support versions prior to PDS3.
  
9:36 Dick Simpson asks whether things like SPREADSHEET will be grandfathered
  into 3.5, or will be 3.6; and will PDS_VERSION_ID = PDS3 include or 
  exclude SPREADSHEET.  CN agrees this should be "PDS3_6" for missions 
  planning to use latest approved changes.  General concern about ambiguity
  of version cut-off.
  
  Anne suggests that this is a CN configuration management issue, and that
  CN should solve it ASAP so that nodes can anticipate version changes and
  development deadlines.  CN already has this on its internal agenda.
  
  Ron asks for a single sentence about grandfathering PDS3.
  
  Dick S. asks about his concern that this SCR does not actually set 
  criteria for establishing version, it only addresses how to determine
  PDS_VERSION_ID value.  Steve H. notes that is a different, larger issue,
  whereas the present SCR is to address only the local DD requirement that
  PDS_VERSION_ID indicate a change.
  
  Dick S. feels this SCR glosses over the change.
  
  Steve H. summarizes issues open so far:
  
    1. Configuration Control - a CN issue being worked
    2. Policy for incrementing standards version ID.  Steve H. believes
       this is a separable issue.
    3. Indicating standards version in labels (this SCR)
    4. Mechanism for indicating DDs used in labels - open.
    
  Ron suggests adding text stating that for labels which adhere to 
  standards version 3.5 or earlier, "PDS3" is the appropriate value.

  General discussion about progress of local DD SCR if this does or doesn't
  pass, and whether this is the appropriate place to start addressing the
  above issues.  No time to converge.
  
T.Brown returns to vote on Local DD Issue:

  Atmos    - Yes
  GEO      - Yes
  Image    - Not Present
  NAIF     - Abstain
  PPI      - Yes
  RS       - Yes
  Rings    - Not Present
  SBN      - No
  Proj Eng - Yes
  CN       - Yes
  
  Vote passes 6-1-3
  
9:59 End