From: Elizabeth D Rye Date: May 3, 2007 7:39:58 AM PDT To: PDS Technical Group Subject: Re: SCR 3-1114 Review standard value output flag values in PSDD Hi All, > You might be sorry you asked about this. I set out to take a look at > the document. I was thinking that a few guidelines is all we need. The > only ones where the values do not need to be displayed are those with > a standard value type of FORMATION and DYNAMIC. For those of type > FORMATION the formation rule should be displayed. Which lead to why > you may be sorry you asked. I looked up DATA_SET_ID on-line and the > dictionary indicates it is of type FORMATION, but that there is no > formation rule specified. Very odd, but it gets even more odd. None of > the elements with a formation rule (DATA_SET_NAME, > DATA_SET_COLLECTION_ID, DATA_SET_COLLECTION_NAME) have rules. Do we > now need an SCR to fix this? First, in response to Todd: I believe the keywords with a standard value type of DYNAMIC *do* need to be displayed. What I'm more skeptical about are the keywords with the standard value type of SUGGESTED. > Steve Hughes, please correct me if/when I'm wrong... > > I seem to remember a (probably offline) conversation with Steve > H. about this some years ago. What I'm remembering is that the > formation rule hook was put in there with the ambitious idea of > developing a syntax for defining ad hoc formation rules for individual > elements that could then be applied by tools like 'lvtool' to validate > entries found in labels and catalog files. This never happened, I'm > guessing because a) it's very hard to do; and b) it comes up fairly > infrequently and there were many more urgent problems to be solved at > the time (and pretty much ever since). > > If the code exists to store FORMATION_RULE_DESC values in the PSDD > database AND to reproduce them in the psdd.full file (for ready > reference), then it would, I think, be feasible to provide some > documentation for most of these, even if it only consisted of > something like "See PDS/SR Section X.X". Or perhaps a separate > appendix specifically to hold the formation rules would be in order. > I count only 30 keywords with this STANDARD_VALUE_TYPE right now, > although there is some inconsistency in its use. For example, things > like EARTH_RECEIVED_TIME have a STANDARD_VALUE_TYPE of "FORMATION" > presumably because they are required to be ISO-formatted dates/times. > But START_TIME has a STANDARD_VALUE_TYPE of "NONE". In general, where > there are formation rules at work they are included in the DESCRIPTION > for the keyword. > > I'm not entirely convinced it's worth the effort to analyze the use of > STANDARD_VALUE_TYPEs and formation rule applications for everything in > the PSDD and tease them out into separate fields, but I'll listen to > arguments to the contrary... In response to both of you on the FORMATION_RULE_DESC, yes we need an SCR to fix this (part of the necessary clean-up of the PSDD that is still sitting on a back burner). I like the suggestion of printing the formation rule, if it exists, although as Anne points out, it might make sense to do that in a separate appendix. I have a new suggestion. Why don't we completely ignore the STANDARD_VALUE_OUTPUT_FLAG, and make the decision about what to print to the PDF version based on the STANDARD_VALUE_TYPE? (Then we'd only have to clean up the latter field, which is in somewhat better shape than the former.) Here would be my suggestion as to how to handle the various types: STATIC - print standard values to Appendix A DYNAMIC - print standard values to Appendix A SUGGESTED - print only the first 5 - 10 values to Appendix A, followed by italicized comment indicating that the complete list of values is available in the online PSDD FORMATION - print the formation rule, if it exists, and the first 5 - 10 values (if they exist) to Appendix A, followed by italicized comment indicating that the complete list of values is available in the online PSDD TEXT - do not print standard values, even if they exist (they shouldn't) RANGE - do not print standard values, even if they exist (they shouldn't) DEFINITION - given that I've never understood what this is supposed to mean, I don't have a clue how to handle it. The definition is "Standard values must simply conform to requirements specified in the data element definition." There are 37 keywords with this standard value type; 5 of them have standard values. They are: CONTAMINATION_ID, DATA_QUALITY_ID, FILTER_NUMBER, PREFERENCE_ID, and TARGET_PARAMETER_UNCERTAINTY. Suggestions on what to do with this are welcome. Feedback? Elizabeth ----------------------------------------------------------------------- From: raugh@astro.umd.edu (Anne Raugh) Date: May 3, 2007 3:58:58 AM PDT To: "PDS Technical Group" Subject: RE: SCR 3-1114 Review standard value output flag values in PSDD Reply-To: raugh@astro.umd.edu (Anne Raugh) > You might be sorry you asked about this. I set out to take a look at > the document. I was thinking that a few guidelines is all we need. The > only ones where the values do not need to be displayed are those with > a standard value type of FORMATION and DYNAMIC. For those of type > FORMATION the formation rule should be displayed. Which lead to why > you may be sorry you asked. I looked up DATA_SET_ID on-line and the > dictionary indicates it is of type FORMATION, but that there is no > formation rule specified. Very odd, but it gets even more odd. None of > the elements with a formation rule (DATA_SET_NAME, > DATA_SET_COLLECTION_ID, DATA_SET_COLLECTION_NAME) have rules. Do we > now need an SCR to fix this? Steve Hughes, please correct me if/when I'm wrong... I seem to remember a (probably offline) conversation with Steve H. about this some years ago. What I'm remembering is that the formation rule hook was put in there with the ambitious idea of developing a syntax for defining ad hoc formation rules for individual elements that could then be applied by tools like 'lvtool' to validate entries found in labels and catalog files. This never happened, I'm guessing because a) it's very hard to do; and b) it comes up fairly infrequently and there were many more urgent problems to be solved at the time (and pretty much ever since). If the code exists to store FORMATION_RULE_DESC values in the PSDD database AND to reproduce them in the psdd.full file (for ready reference), then it would, I think, be feasible to provide some documentation for most of these, even if it only consisted of something like "See PDS/SR Section X.X". Or perhaps a separate appendix specifically to hold the formation rules would be in order. I count only 30 keywords with this STANDARD_VALUE_TYPE right now, although there is some inconsistency in its use. For example, things like EARTH_RECEIVED_TIME have a STANDARD_VALUE_TYPE of "FORMATION" presumably because they are required to be ISO-formatted dates/times. But START_TIME has a STANDARD_VALUE_TYPE of "NONE". In general, where there are formation rules at work they are included in the DESCRIPTION for the keyword. I'm not entirely convinced it's worth the effort to analyze the use of STANDARD_VALUE_TYPEs and formation rule applications for everything in the PSDD and tease them out into separate fields, but I'll listen to arguments to the contrary... -Anne. ----------------------------------------------------------------------- From: "Todd King" Date: May 2, 2007 8:23:10 PM PDT To: "PDS Technical Group" Subject: RE: SCR 3-1114 Review standard value output flag values in PSDD Reply-To: "Todd King" Hi Elizabeth - You might be sorry you asked about this. I set out to take a look at the document. I was thinking that a few guidelines is all we need. The only ones where the values do not need to be displayed are those with a standard value type of FORMATION and DYNAMIC. For those of type FORMATION the formation rule should be displayed. Which lead to why you may be sorry you asked. I looked up DATA_SET_ID on-line and the dictionary indicates it is of type FORMATION, but that there is no formation rule specified. Very odd, but it gets even more odd. None of the elements with a formation rule (DATA_SET_NAME, DATA_SET_COLLECTION_ID, DATA_SET_COLLECTION_NAME) have rules. Do we now need an SCR to fix this? -Todd- ----------------------------------------------------------------------- From: Dick Simpson 650-723-3525 Date: May 2, 2007 3:40:48 PM PDT To: Elizabeth.D.Rye@jpl.nasa.gov Subject: Re: SCR 3-1114 Review standard value output flag values in PSDD > I meant plowing through the 284 pages and coming up with a suggested > list of keywords whose values don't need to appear in the printed > version of the PSDD. If I do get a volunteer to help out, I'd > probably discuss some basic criteria with them, and then split up the > document into different sections for us to work on. Maybe with a couple sections done by both - for quality control. It's something I might consider if I had some travel coming up and little to keep me busy in airports, rental cars, other time zones. But the next travel is only to Boulder for the NH review; and it's more than a month away. Let me know then if you're still interested when the time comes. ----------------------------------------------------------------------- From: Elizabeth D Rye Date: May 2, 2007 3:25:39 PM PDT To: Dick Simpson 650-723-3525 Subject: Re: SCR 3-1114 Review standard value output flag values in PSDD Hi Dick, I meant plowing through the 284 pages and coming up with a suggested list of keywords whose values don't need to appear in the printed version of the PSDD. If I do get a volunteer to help out, I'd probably discuss some basic criteria with them, and then split up the document into different sections for us to work on. I had presumed that we'd present the proposed list to the TG for review and approval. Elizabeth ----------------------------------------------------------------------- From: Dick Simpson 650-723-3525 Date: May 2, 2007 3:10:43 PM PDT To: Elizabeth.D.Rye@jpl.nasa.gov Subject: Re: SCR 3-1114 Review standard value output flag values in PSDD > I basically need help reviewing the attached Appendix A > to the PDF version of the PSDD and determining which lists of standard > values don't belong in this hard copy version of the Dictionary. Do you mean "comparing" rather than "reviewing"? Don't get your hopes up; I'm just trying to understand the request. ----------------------------------------------------------------------- From: Elizabeth D Rye Date: May 2, 2007 3:02:53 PM PDT To: PDS Technical Group Subject: SCR 3-1114 Review standard value output flag values in PSDD Hello All, I'm looking for a couple of volunteers to be on a working group with me on this SCR. I basically need help reviewing the attached Appendix A to the PDF version of the PSDD and determining which lists of standard values don't belong in this hard copy version of the Dictionary. The description of this SCR is available at: http://pds-engineering.jpl.nasa.gov/index.cfm?pid=2&cid=63&scrid=3-1114 Please get back to me if you're interested. Thanks! Elizabeth ----------------------------------------------------------------------- From: standards_coordinator@jpl.nasa.gov Date: May 2, 2007 2:25:22 PM PDT To: standards_coordinator@jpl.nasa.gov, Elizabeth.D.Rye@jpl.nasa.gov Subject: New SCR 3-1114 submitted SCRID: 3-1114 Title: Review standard value output flag values in PSDD SCR Type: SCR Summary: "Since regular printing of the PSDD ceased roughly a decade ago, we (as an organization) have not been paying strict attention to the value of the standard value output flag for each keyword. This is the flag in the PSDD that determines whether or not the standard values for a keyword are output for hard copy display. In the case of the PDF version of the PSDD, Appendix A, which contains the list of standard values, has grown from 66 pages in 1996 to 284 pages today. Many of the keywords for which this value is set to 'Y' either have no standard values, or have standard values which it makes no sense to display in this context. Since these values are always available via the online interface, I believe it would appropriate to review the list of keywords with the value set to 'Y' and determine which of them should be updated to 'N'. In the process, we should probably also review if there are currently values of 'N' which should be changed to 'Y'. " Priority: high Deadline: Originator: Elizabeth Rye Email: Elizabeth.D.Rye@jpl.nasa.gov Lead: E. Rye Working Group: NULL Tester: no