validate configuration includes context product names that do not match the products
Checked for duplicates
No - I haven't checked
🐛 Describe the bug
In at least one case the value of a name in registered_context_products.json doesn't seem to match that in the context product label. In the json we see:
{
"name": [
"CAL TARGET"
],
"type": [
"CALIBRATION FIELD"
],
"lidvid": "urn:nasa:pds:context:target:calibration_field.cal_target::1.0"
},
but the corresponding context product (https://pds.nasa.gov/data/pds4/context-pds4/target/calibration_field.cal_target_1.0.xml) has (abbreviated):
<Target>
<name>CAL_TARGET</name>
<type>Calibration Field</type>
<description> <snip></description>
</Target>
so validate is warning about CAL_TARGET as name in a product label (it expects CAL TARGET even though it matches the context product).
🕵️ Expected behavior
I expected that validate maintains the context product names "as is" from the labels.
📜 To Reproduce
Validate any product referencing the above target context.
🖥 Environment Info
- Version of this software: validate 3.5.2
- Operating System: Mac with java 17
📚 Version of Software Used
validate 3.5.2
🩺 Test Data / Additional context
No response
🦄 Related requirements
🦄 #xyz
⚙️ Engineering Details
No response
🎉 Integration & Test
No response
@msbentley it looks like this is a bug with how we are loading the data into the database where this field appears to be tokenized. This will hopefully be fixed with an upgrade of the system (expected in the next couple weeks) and/or a switchover to use the new API to get this information.
Great, thanks @jordanpadams
I'd like to add on that all of the telescopes in the registered_context_products.json file have N/A for the name and type. It's another thing to check, at least, once the process is updated.
Example:
{
"name": [
"N/A"
],
"type": [
"N/A"
],
"lidvid": "urn:nasa:pds:context:telescope:lowell.loneos_0m60::1.2"
},
I just ran into the telescope sub-issue. The schema for Telescope (unlike Instrument) has no name or type, so presumably that's why those fields are N/A. Not sure how you want to resolve this, maybe by not checking when the referenced LID is a telescope. The attached example actually has a telescope as the target (as well as an observing component) - I actually encountered that in a review. Archive.zip
The type for Instrument has been deprecated since 1C00, so this will eventually turn into an issue for instruments, as well. That might be another place where you will want to skip the type check. (Or skip it when the value is N/A).
For some of these product types, it seems reasonable to pull them from the title in Identification Area, as well. I think that's why there was no name attribute in Telescope, for instance. The Identification Area also stores an alias list, which should probably be included.
@msbentley I think this should be fixed with some past updates.. Let me know if you still encounter this issue.