-
Notifications
You must be signed in to change notification settings - Fork 1
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
Gem breaking on extraneous attributes #104
Comments
FWIW, this issue is not occurring with isotc204-glossary. A different bug is, and I will be reporting that too. |
@opoudjis Glossarist supports a config file which can be used to define extra attributes that are not in the concept model. For that we just need to create a |
Ok, so:
Correct? |
Correct, We can have a
Yes, I will update the documentation, once I finalized the current task related to lutaml/lutaml-model#2. I've added a ticket for that here -> #105 |
And glossarist.yaml tells it that Anyway, the document is compiling now... |
So this problem will be fixed when we migrate to lutaml-model. I just ran into this exact same problem when trying to use a Glossarist dataset that can be loaded by Paneron. |
In pursuit of metanorma/metanorma#75, I created the following document, as instructed:
This is the barest of bare minimums of integration.
I get:
And indeed, status is not defined in either Concept, or LocalizedConcept; only entry_status is defined in the latter.
status in the localized-concept YAMLs of isotc211-glossary is set to be "valid".
I don't know anything about the termbases we are publishing, and I'm not going to: I only care about Metanorma. What I do see though is that random YAML is going to be fed into this gem from all sorts of sources, and this gem must be defensive about what it reads in that YAML, or it simply cannot be used.
Which means that "fix the isotc211-glossary dataset" is not the right response to this, even if you end up doing that anyway. (And I would not: saying a term is valid is entirely legit.) The right response is to anticipate that the YAML that will be read in by this gem will contain all sorts of extraneous fields, and to make sure that Glossarist ignores them, rather than naively trying to shove them into its model.
I do need to add that if glossarist-ruby and metanorma-plugin-glossarist are going to be made available to the Metanorma stack, there is an obligation to do integration testing, including with such new termbases as we publish. We should not be making https://github.com/geolexica/isotc211-glossary available without ensuring that glossarist-ruby can read it: that is our organisational responsibility, as publishers of both.
The text was updated successfully, but these errors were encountered: