Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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
@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:
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