Standards Telecon - Local Data Dictionary - 6/4/2003

9:02 Start

Attendees
C.Acton		T.Brown		P.Garcia	M.Gordon
L.Huber		S.Hughes	R.Joyner	T.King
A.Raugh		D.Simpson	S.Slavney	B.Sword
J.Wilf		J.Zender

R.Joyner - agrees change STANDARD_VALUE_TYPE to dynamic
S.Slavney - wants to state for the record that this decision has an impact on MEX
J.Zender - impact on ESA missions is large, and ESA will pay the cost
R.Joyner - E.Rye has a problem with 60 character limit on NAMESPACE_ID keyword
A.Raugh - brings up logical inconsistencies with namespace_id usage - T.King agrees
T.King - solution is element name, namespace is the element it's in
T.King - what about open issues?
R.Joyner - steps through open issues...

Open issues:
============
  The following are the set of open issues that the working group felt
  should be noted as possible topics for discussion within the technical group:

(1) An SCR needs to be written to set a policy for incrementing PDS_VERSION_ID,
    and should address finer granularity (e.g., PDS_VERSION_ID = PDS3.x).
    The working group thought that the changes specific to this SCR warrant
    a change from PDS_VERSION_ID = PDS3, but do not warrant a change to PDS4.

A.Raugh - needs to be addressed, and changed so s/w won't be broken, assuming PDS3
T.King - do we want to go from PDS 3 to 3.1 or 4?
S.Hughes - do we need to change the version id? how do we do that change?
L.Huber - should have changed when GROUP change went through...
A.Raugh - will break lvtool
S.Hughes - need version change, but not sure how
J.Wilf - need to visit the whole issue of versioning
S.Slavney - need rules for changing a version
B.Sword - must be history for change
S.Slavney - SCR should go ahead, but rules needed for version change
A.Raugh - should the presence of the ldd be indicated by a version change?
          Says R.Joyner made a compromise to use DD version (3.6)
T.King - this shouldn't hold up this SCR
A.Raugh leaves
L.Huber - agree
S.Slavney - agree
S.Hughes - does a change have to be indicated?, and it should be discussed?

VOTE held on change needed unanimous

S.Hughes - will write the draft SCR

J.Wilf - this is a new thing - a Standards implementation lien !!!
T.King - SCR can go ahead, but can't implement
J.Wilf - 1st vote do we stop the process to figure out versioning?

VOTE passes with one no (A.Raugh proxy)

J.Wilf - 2nd VOTE to impose implementation lien on versioning

VOTE passes - 10 votes for, w/ A.Raugh not present and R.Joyner & D.Simpson
against, reservations by L.Huber (sunset clause), S.Slavney (same), B.Sword
(fear & trembling)


(2) Use of namespace should not be limited to missions / campaigns.

R.Simpson - missions vs nodes better distinction
M.Gordon - should retain possibility of other distinctions
R.Simpson - node should have authority to delegate entirely
T.Brown - is CN a Node for this purpose
S.Hughes - yes
J.Wilf leaves

Vote: Should nodes have namespace authority?  Change missions/campaigns to node.

VOTE passes - 11 yes, with J.Zender voting NO - missions outside of US shouldn't 
have to come to PDS to define namespace - As a result of this dissent, group 
agrees to add clause "...or other agencies in cooperative agreement w/ NASA"


(3) Introduction should be rewritten to not reflect "lowering of standards".

R.Simpson - won't volunteer to rewrite this one
  It was decided that this concern won't stop process, so no vote


(4) Embedding namespace as part of element name may not be the best approach.

A.Raugh's issue - not here
S.Hughes - we have concept of namespace, and the question is whether PDS is
  implementing namespace or whether the issue is local
T.King - namespace/ID correlation important
M.Gordon - we send this to MC and we embed namespace in element name
M.Gordon - two options, but let it go
M.Gordon - vote as to whether this issue

VOTE fails (don't send to MC, issue removed from list)- 2 Yes (J.Zender, A.Raugh
proxy), 8 No, 3 abstentions (C.Acton, R.Simpson, B.Sword)


(5) Limiting scope of use of locally defined keywords (e.g., do not use for
correlative searches) - see Section 5.5.3(9).

M.Gordon - keywords should not be used outside the defined namespace - (9)
  should be altered as to not limit cross-correlative searches WITHIN a mission
T.King - can other missions use keywords?
M.Gordon/J.Zender - discussion on local vs central keywords
S.Hughes - J.Zender is right, what if keyword gets promoted?
S.Hughes - Pandora's box for local keywords to become popular, and used outside
  of mission
M.Gordon - propose vote to reword (9)
J.Zender - gone

VOTE passes 6,2,3 (C.Acton, P.Garcia, M.Gordon, L.Huber, T.King, S.Slavney
for),  (B.Sword, R.Joyner No), (S.Hughes, J.Wilf, R.Simpson abstain), (A.Raugh
and J.Zender gone)


(6) Is a sanity check of locally defined keywords by DN and peer-review
committee sufficient ???

S.Hughes - Is DE review overkill?

Vote - Yes is to retain (6). A NO means (6) above is insufficient

VOTE is whether to retain (6) - 10 yes, 1 no (R.Simpson who wants more CN
involvement) - a note should be made to retain this concern for lifecycle or
procedural processes

R.Joyner reads list of changes he'll make in SCR:
(1) Add defintion of custodian
(2) Change mission/campaign to custodian
(3) Change 5.5.3(9)
(4) Change last page where to remove Open Items and insert Implementation Lien.