Difference between revisions of "PSA Dictionary"
(Safety Save) |
(Safety Save) |
||
Line 228: | Line 228: | ||
---- | ---- | ||
− | = Schematron | + | = Schematron Notes = |
− | There are hard-coded rules to check that context reference LIDs follow very specific naming rules and are in the PSA namespace. These appear to follow the PDS3 catalog object relationships. | + | * There are hard-coded rules to check that context reference LIDs follow very specific naming rules and are in either the PSA or PDS namespace, depending on context object type. These appear to follow the PDS3 catalog object relationships. Seems like this would be problematic for Rosetta and long-term. |
+ | * Product_Document is prohibited in data collections. This is problematic for overview documents. | ||
+ | * All observational products are required to have a spacecraft somewhere in their observing system. This is problematic for the ground-based data. | ||
+ | * There is a rule enforcing the prohibited targets mentioned in the conventions document by testing against the context LIDs. | ||
+ | * There is a rule requiring Investigation_Area in Observation_Area (where it is schematically required anyway) and Context_Area (where it is not). | ||
+ | * There is a rule limiting all collection ID segments to the list in the conventions document. | ||
+ | * There is a rule requiring the present of at least one Mission_Area in Observation_Area (but not in Context_Area). | ||
+ | * There is a rule requiring Modification_History in the Identification_Area. | ||
+ | * There is a rule excluding '''telemetry''' as a processing_level. | ||
+ | * There is a rule that appears to think it is limiting data collections to contain only Product_Observational products, but it instead requires that a Product_Observational is inside a "data_*" collection (which isn't quite the same thing. | ||
+ | * There is a rule that duplicates the schematic requirement that an Observation_Area contain an Observing_System class. | ||
+ | * Primary_Result_Summary, Science_Facets, and at least one Observing_System_Component of type '''Instrument''' are required in Product_Observational. |
Revision as of 13:29, 29 May 2019
PDS Schema, version 1.1.0.1, from the XSD and Schematron files.
Exposed Elements:
- Mission_Information
- Observation_Context
- Processing_Context
- Quality_Information
- Sub-Instrument
Note that none of the classes or attributes is defined.
Contents
<Mission_Information>
REQUIRED
Required by Schematron rules.
<spacecraft_clock_start_count>
OPTIONAL
ASCII string; no validation.
<spacecraft_clock_stop_count>
OPTIONAL
ASCII string; no validation.
<mission_phase_name>
REQUIRED
ASCII string; no validation.
<mission_phase_identifier>
OPTIONAL
ASCII string; no validation.
<start_orbit_number>
OPTIONAL
Non-negative integer
<stop_orbit_number>
OPTIONAL
Non-negative integer; not validated against start_orbit_number.
<Observation_Context>
OPTIONAL
No minimal existential requirement for content.
<instrument_pointing_mode>
OPTIONAL
Must have one of these values:
- Surface
- Atmosphere
- Limb
- No Pointing
- Space
<instrument_pointing_description>
OPTIONAL
ASCII string limited to 255 characters and no formatting.
<observation_identifier>
OPTIONAL
ASCII string; no validation.
<Processing_Context>
OPTIONAL
<processing_software_title>
REQUIRED
ASCII string
<processing_software_version>
REQUIRED
ASCII string
<Processing_Inputs>
OPTIONAL
<Processing_input_Identification>
REQUIRED, repeatable
<type>
REQUIRED
Must be one of:
- telemetry
- PDS product
- SPICE kernel
- auxiliary
Note that there is an empty Schematron rule on the equivalent context and some dicey syntax in the rule with the standard values that make this validation problematic.
<file_name>
REQUIRED
<pds:Internal_Reference>
OPTIONAL
No values are defined for <pds:reference_type> in this class.
<Quality_Information>
OPTIONAL
<quality_flag>
REQUIRED
ASCII string
Note that the value is unconstrained in any way (as well as undefined).
<Sub-Instrument>
OPTIONAL
<identifier>
REQUIRED
ASCII string
<name>
REQUIRED
ASCII string
<type>
REQUIRED, repeatable for up to 3 values
Must be one of:
|
|
|
|
<subtype>
OPTIONAL, not repeatable
ASCII string.
Note that there is an empty Schematron rule where one would expect a permissible values list.
Schematron Notes
- There are hard-coded rules to check that context reference LIDs follow very specific naming rules and are in either the PSA or PDS namespace, depending on context object type. These appear to follow the PDS3 catalog object relationships. Seems like this would be problematic for Rosetta and long-term.
- Product_Document is prohibited in data collections. This is problematic for overview documents.
- All observational products are required to have a spacecraft somewhere in their observing system. This is problematic for the ground-based data.
- There is a rule enforcing the prohibited targets mentioned in the conventions document by testing against the context LIDs.
- There is a rule requiring Investigation_Area in Observation_Area (where it is schematically required anyway) and Context_Area (where it is not).
- There is a rule limiting all collection ID segments to the list in the conventions document.
- There is a rule requiring the present of at least one Mission_Area in Observation_Area (but not in Context_Area).
- There is a rule requiring Modification_History in the Identification_Area.
- There is a rule excluding telemetry as a processing_level.
- There is a rule that appears to think it is limiting data collections to contain only Product_Observational products, but it instead requires that a Product_Observational is inside a "data_*" collection (which isn't quite the same thing.
- There is a rule that duplicates the schematic requirement that an Observation_Area contain an Observing_System class.
- Primary_Result_Summary, Science_Facets, and at least one Observing_System_Component of type Instrument are required in Product_Observational.