Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

validate configuration includes context product names that do not match the products #967

Open
msbentley opened this issue Aug 6, 2024 · 5 comments
Assignees
Labels
B15.0 bug Something isn't working s.medium

Comments

@msbentley
Copy link

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

@jordanpadams
Copy link
Member

@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.

@msbentley
Copy link
Author

Great, thanks @jordanpadams

@jstone-psi
Copy link

jstone-psi commented Aug 27, 2024

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"
          },

@rchenatjpl
Copy link

rchenatjpl commented Sep 26, 2024

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

@jstone-psi
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B15.0 bug Something isn't working s.medium
Projects
Status: Release Backlog
Status: ToDo
Development

No branches or pull requests

5 participants