Bug fix: mandatory fields are handled better when not filled in #71
Conversation
bedroesb
changed the title
nan problem
|
Puh this is gross :) Can you add a comment to the template generator why this is needed and do you see any way how we can test this? |
|
@bgruening I know this does not look pretty ;) I found a nicer solution but problem is that the error that was thrown from the XSD validator was about the XML and not about to tsv/xlsx input file + it was not triggered when When it comes to testing, we would need many files in the current situation, because it stops the script when it encounters the first one. I don't know if I can keep track in the template of the errors so if the XML generation is done I know in the main python script there where errors 🤔 |
|
We need a rebase here :( |
|
@bgruening wel good is relative, "Puh this is gross :)" still applies sadly haha! I think it might benefit to have a look in how we could change the way we fill in the XMLs currenlty |
This PR fixes certain weird behaviors. Before when the table was not filled in at a column that is mandatory, or just NA, the validator would not complain. It would only complain when a field is missing that has a controlled vocabulary.
Now all mandatory attributes got wrapped with an if statement that stops the script when missing. It is done this way because if the
<key></key>is included, but is empty, the validator will not complain, because it is present + now the error will not appear if the platform or instrument model is not given that lowercase can not be applied to nan objects.