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

Allow scalar data sources in json metadata descriptor #527

Merged
merged 2 commits into from
Feb 25, 2025

Conversation

vpinna80
Copy link
Collaborator

@vpinna80 vpinna80 commented Dec 2, 2024

This patch allows the json metadata file to also represent scalar values. It's a terminology change to make the change more evident.

@hadrienk
Copy link

hadrienk commented Dec 2, 2024

Should we take the opportunity to version the schema so we can make these changes without breaking implementations?

@vpinna80
Copy link
Collaborator Author

vpinna80 commented Jan 8, 2025

I'll prepare another pull request to start a versioning of the guidelines.

@antonio-olleros
Copy link

For me the change in terminology, but I'm not sure with this change how would scalars be represented, can you please clarify, @vpinna80 ?

Regarding versioning, I would be careful, because versioning is not included in the standard...

@vpinna80
Copy link
Collaborator Author

For me the change in terminology, but I'm not sure with this change how would scalars be represented, can you please clarify, @vpinna80 ?

the scalars would be represented by directly inputing a value domain instead of a structure name:

{
  "data": [
    {
      "name": "DS_1",
      "metadata": "DS_1_str"
    },
    {
      "name": "an_integer_scalar"
      "metadata": "integer"
    },
    {
      "name": "a_country_scalar"
      "metadata": "CL_COUNTRY"
    }
  ]
}

@antonio-olleros
Copy link

I see, thanks for the clarification.
Wouldn't it make sense to add a property type, with possible values {'structure', 'scalar', 'valuedomain'}? Other wise we need to implement logic to find out what it is, and we can have conflicts (e.g., someone decides to have a valuedomain and a structure with the same name...)

@vpinna80
Copy link
Collaborator Author

@antonio-olleros you have good eyes... I'll make a different proposal.

Regarding the versioning, please move that discussion to #531

@vpinna80
Copy link
Collaborator Author

Here's the example with the new proposal, i used two alternative properties to maintain compatibility with the previous json:

{
  "data": [
    {
      "name": "DS_1",
      "structure": "DS_1_str"
    },
    {
      "name": "an_integer_scalar"
      "valuedomain": "integer"
    },
    {
      "name": "a_country_scalar"
      "valuedomain": "CL_COUNTRY"
    }
  ]
}

@antonio-olleros
Copy link

Thanks for the suggestion, @vpinna80! Still not fully convinced, for me the data types are not the same as valuedomains, but the valuedomains are defined on basic scalar types (see: https://sdmx-twg.github.io/vtl/2.1/html/user_manual/model.html#the-variables-and-value-domains-artefacts).

I think this is relevant enough to be worth having a meeting...

@vpinna80
Copy link
Collaborator Author

I hope there will be one session about it in Frankfurt, right @linardian ?

@linardian
Copy link
Collaborator

Yes, of course! I am inserting this topic in the agenda.

@linardian linardian marked this pull request as ready for review February 25, 2025 09:27
@linardian linardian closed this Feb 25, 2025
@linardian linardian reopened this Feb 25, 2025
@linardian linardian merged commit 167af3f into master Feb 25, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants