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
clarify validation rules #306
Comments
Also provided a pseudo-code example of validation logic, as requested in issue #306.
I reworked the validation rules, which are now much more explicit in the specification. Please review here: https://github.com/NCEAS/eml/blob/BRANCH_EML_2_2/docs/eml-validation-refs.md @cboettig and @csjx Could you take a look at these and make sure everything seems complete? |
See my take on the validation rules in ropensci/emld#26 (as code and with a few minor questions) |
reads clearly; made a few grammatical edits |
@mbjones Can you clarify a few things for me:
An aside, but the way EML sometimes specifies IDs as attributes and sometimes as node content leaves some open questions in my mind as well. (The first gotcha I learned was that we should probably assert trimming whitespace around ids given as node values.) Not sure if there are other risks here with regard to parsing rules (e.g. thinking about things like Lastly, note that I think one of the current test files does not satisfy these validation rules; the annotation: eml/src/test/resources/eml-data-paper.xml Lines 151 to 154 in 3a751d0
appears as the child of a |
@cboettig Thanks for the feedback...
This is open to discussion, but my thought is yes -- it represents the whole package, whereas an
The schema contains an enumeration of standard unit names which is used to validate that field with the overall XML validation, but I agree it would be good to check customUnit against the provided unitList.
Not currently. Do you think it should?
Yeah, I'm torn on this. We originally planned to have the
Possibly. I meant for the step "If the element containing the id contains a
Yeah, I agree, and I have fixed that and will look for others. When I finish the new java-based parser (soon) I will make sure that all the test docs pass, except the ones in the |
EML has had additional rules for validation that were somewhat opaquely described in section 3.3 of the spec. Clarify and update these rules to make it crystal clear what a conformant parser should be testing for.
The text was updated successfully, but these errors were encountered: