Comments (11)
I would be more in favor of an empty string rather than a null/None value, is there a way to match null values to empty strings? @christian-rli - do you have a better idea of the specification here?
I have no preference over null vs "", but If I recall correctly, @MGlauer was in favor of using null because an empty string represents a different information than null. One may interpret null directly as no value here while an empty string could mean just that - a string of zero length. In any case, changes to 1.4 are forbidden now :) So if you'd like to change that, it should go into the discussion for 1.5. We still need to decide on a place for that discussion and I hope @Ludee @MGlauer , the others and I can agree on a place for that during the next two days.
from omi.
Hi @Bachibouzouk,
one thing more! If try to validate the JSON metadata example (v1.4 from examples: link) I get an error:
jsonschema.exceptions.ValidationError: None is not of type 'string'
For this to not happen, null values must be allowed: https://stackoverflow.com/a/16241482
This leads to some questions:
- Shall I add null values allowed to JSON schema? Example:
"location": {"type": "string, null"}
- Is nulling of all values allowed? Or only specific ones? And if so which ones?
from omi.
one thing more! If try to validate the JSON metadata example (v1.4 from examples: link) I get an error:
By using the schemas in examples/metadata/archiv/ I don't have this problem.
I would be more in favor of an empty string rather than a null/None value, is there a way to match null values to empty strings? @christian-rli - do you have a better idea of the specification here?
from omi.
And second question, where is the description of v1.3
As far as I know there is no clean one and we won't do it because we don't want people to use v1.3 anymore. We should just make sure that an existing v1.3 will not make the OEP website crash and can be rendered. @christian-rli made the description of the v1.4
from omi.
I think the possibility of adding descriptions is very handy and shouldn't be missed, because we could get rid of https://github.com/OpenEnergyPlatform/examples/wiki/Metadata-Description and could point
$id
directly to a single JSON schema file (that is self describing).What do you think? Shall I add the description of v1.4 into the schema draft?
I find it a sweet idea/solution :). What do you think @MGlauer , @Ludee , @christian-rli ?
from omi.
I think the possibility of adding descriptions is very handy and shouldn't be missed, because we could get rid of https://github.com/OpenEnergyPlatform/examples/wiki/Metadata-Description and could point
$id
directly to a single JSON schema file (that is self describing).
What do you think? Shall I add the description of v1.4 into the schema draft?I find it a sweet idea/solution :). What do you think @MGlauer , @Ludee , @christian-rli ?
Thank you @4lm and @Bachibouzouk for your work on the json-schema drafts! I wasn't aware of the option to add descriptions in a schema file and also think that it's a very elegant solution to provide the description. So from my end it's a "GO".
I was missing a nice online description of 1.3 and therefore created the one for 1.4. @Ludee published a description of 1.3 in a collection somewhere, but there seems to be no online access or link I could share. I'm going to send you an internal link to the file via mail.
from omi.
@Bachibouzouk: By using the schemas in examples/metadata/archiv/ I don't have this problem.
The JSON file in there is an empty template JSON file, which doesn't contain null values. If you take one the example files (SQL in examples/metadata/archiv/
or JSON file in examples/metadata/
), it will fail because it contains null values.
@christian-rli: I have no preference over null vs "", but If I recall correctly, @MGlauer was in favor of using null because an empty string represents a different information than null. [...] In any case, changes to 1.4 are forbidden now :) So if you'd like to change that, it should go into the discussion for 1.5.
I have the same opinion as @MGlauer and empty string is not the same as a null value. Because of that we also have to possibility to define mandatory and non-mandatory fields in the schema. That's a thing we IMO should work with ...
from omi.
In case we want to set mandatory and non-mandatory fields (nullable/non-nullable), I want to emphasize my question from above:
Is nulling of all values allowed? Or only specific ones? And if so which ones?
Edit: Mandatory fields should be defined via "required" list: http://json-schema.org/learn/getting-started-step-by-step.html
EditEdit: So, the first decision to make would be is the specific field mandatory and second is field allowed to be a null value.
from omi.
@christian-rli: also think that it's a very elegant solution to provide the description. So from my end it's a "GO".
Cool, will start to work on it! If anyone has objections, now is a good time 😉
from omi.
First draft of schema definition with description. Please head to #19 and have a look ...
from omi.
I'm closing this issue. There is a metadata repo now: https://github.com/OpenEnergyPlatform/metadata
from omi.
Related Issues (20)
- Source code is cluttered
- New validation function needed
- Conversion update for 1.5.2, 1.6 and 2.0
- More Error messages needed HOT 4
- Conversion creates empty fields when adding new metadata keys
- The metadata generated by the omi compiler has a modified key sequence HOT 1
- Documentation on how to use conversion is missing in RTD and Readme
- Include the metadata validation scripts from the oedatamodel HOT 14
- omi compiler for oemetadata results in some unexpected key names
- Adapt to github actions from travis
- OMI omits `null` values from json during processing
- Compiling metadata with minimum or empty fields causes a NoneType error.
- Return error report in OMI validation
- Inconsistent omi field names compared to oemetadata spec
- Evaluate integration of functions to generate metadata with ioprocmeta HOT 1
- metadata parser wrongly adds current date to temporal metadata
- Add new Issue-Templates
- Document and reuse existing methods to (auto-)generate OEMetadata
- Minor improvements to the key sequence and some api enhancements
- OMI rewrite
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from omi.