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

Context product aliases are ignored for context_ref_mismatch #945

Closed
rgdeen opened this issue Jun 27, 2024 · 3 comments
Closed

Context product aliases are ignored for context_ref_mismatch #945

rgdeen opened this issue Jun 27, 2024 · 3 comments
Assignees
Labels
bug Something isn't working duplicate This issue or pull request already exists needs:triage

Comments

@rgdeen
Copy link

rgdeen commented Jun 27, 2024

Checked for duplicates

Yes - I've already checked

🐛 Describe the bug

I was running some m20 validations for testing, with the latest validate (3.5.1) and there is a new warning type, warning.label.context_ref_mismatch, which is problematic.

The warnings look like this:

        {
          "severity": "WARNING",
          "type": "warning.label.context_ref_mismatch",
          "line": 64,
          "message": "Context reference name mismatch. Value: 'Mars2020' Expected one of: '[MARS 2020]'"
        },
        {
          "severity": "WARNING",
          "type": "warning.label.context_ref_mismatch",
          "line": 74,
          "message": "Context reference name mismatch. Value: 'Mars 2020' Expected one of: '[Perseverance]'"
        },
        {
          "severity": "WARNING",
          "type": "warning.label.context_ref_mismatch",
          "line": 83,
          "message": "Context reference name mismatch. Value: 'Cache Camera' Expected one of: '[ENGINEERING CAMERA SUITE (ECAM)]'"
        }

Now, we have a problem because for m20 ecam, we specifically use the "instrument:mars2020.ecam" context product, which covers a whole bunch of individual cameras, and then use under Observing_System_Component to say exactly which camera it is. (BTW, this is another good use case for the instrument-host-hierarchy SCR (#20)).

This could be solved by adding a bunch of Aliases to the context product. However... validate seems to ignore these. I found that the InSight spacecraft context product has an alias (nsyt). So I hacked up a sample label to use it:

      <Observing_System_Component>
        <name>InSight</name>
        <type>Host</type>
        <Internal_Reference>
          <lid_reference>urn:nasa:pds:context:instrument_host:spacecraft.insight</lid_reference>
          <reference_type>is_instrument_host</reference_type>
          <comment>This is the PDS4 logical identifier for the Mars 2020 spacecraft.</comment>
        </Internal_Reference>
      </Observing_System_Component>

Validates fine with name=InSight. But if I put in name=nsyt, which is an alias in the context product, it fails. From the context product:

        <Alias_List>
            <Alias>
                <alternate_id>nsyt</alternate_id>
                <alternate_title>nsyt</alternate_title>
            </Alias>
        </Alias_List>

🕵️ Expected behavior

I expected context-product aliases to be honored in this new warning. If it doesn't, what is the purpose of an Alias?

I realize this warning can be turned off by --disable-context-mismatch-warnings ... but we should not have to do that.

I also realize that the m20 context products all need to be updated to include the relevant aliases, but there's not much point in that until validate is fixed.

📜 To Reproduce

Take just about any label and add the OSC paragraph shown above, for insight. Change name to 'nsyt' instead of 'InSight' to show that the aliases are not honored. (note, it does not have to be an insight product to do this).

🖥 Environment Info

linux

📚 Version of Software Used

validate 3.5.1

🩺 Test Data / Additional context

No response

🦄 Related requirements

🦄 #xyz

⚙️ Engineering Details

No response

🎉 Integration & Test

No response

@jordanpadams
Copy link
Member

@rgdeen the intended functionality for the requirement was strict matching with the name value. I will create a new requirement to support less strict matching (Aliases, additional whitespace/dashes/etc.)

@rgdeen
Copy link
Author

rgdeen commented Jul 10, 2024

I'm somewhat ambivalent about things like dashes not matching, but matching aliases would be greatly appreciated. Thanks!

@jordanpadams
Copy link
Member

Since this is a new requirement, not a bug, closing for #970

@github-project-automation github-project-automation bot moved this from ToDo to 🏁 Done in EN Portfolio Backlog Aug 9, 2024
@jordanpadams jordanpadams added the duplicate This issue or pull request already exists label Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working duplicate This issue or pull request already exists needs:triage
Projects
Status: 🏁 Done
Development

No branches or pull requests

2 participants