-
Notifications
You must be signed in to change notification settings - Fork 7
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
TG2-AMENDMENT_DAY_STANDARDIZED #127
Comments
Need a clear definition of what things this amendment should attempt to do. Based on the example, I would suggest removing all non-numeric characters and attempting to parse an integer in the range of 1-31 out of the remaining characters. I would propose explicitly excluding roman numerals from translation here (as their presence in day suggests a transposition of day and month in the biodiversity domain) (MUST_NOT translate roman numerals to integers). Unclear if text "first", "second", etc, and in languages other than English should or should not be supported. If an upstream data preparation test, may need to translate numbers from more parts of the unicode character set into integers, this might be a MAY condition. |
These are tests not in our original suite of tests, and like Paul, I question their value as CORE. I know some good arguments were put forward in Gainesville where some easy one may be corrected (as in example), but we excluded a number of other tests on Day and Month as we didn't regard those fields as CORE (other than helping to populate eventDate. I can see arguments for keeping YEAR as I know a lot of people use this on its own, but DAY and MONTH less so. I agree with @chicoreus - move to SUPPLEMENTAL |
I would agree with SUPPLEMENTAL for dwc:day |
I am not sure our description for this is good. Perhaps we should add "unambiguously" interpreted. For example do we want to convert "32" to "23" - other examples? |
I agree about "unambiguosly"...will edit in. That makes "32" ambiguous as it could be "23" or "13" with typo etc. |
Let's pose some examples, with some alternatives included:
We could define this test as removing strings that appear to be ordinal indicators and proposing a bare integer, so long as it is in the range 1 to 31 inclusive. Or we could define this test as checking to see if the day contains a single integer in the range 1 to 31, and if so, removing all other characters from the day value. Or... |
So, where are we with this? Various TAGS have been added, removed, re-added etc. TIME resolution to day makes this less important than month and year but does this alone make it NOT_CORE? @chicoreus provides examples where we could unambiguously AMEND (e.g., "one", "two", "thirty one", "first", "second", "thirty first","1st", "2nd", "31st". Comments please. |
…and added unit tests resulting from Arthur Chapman's ongoing review of results of test runs. DESCRIPTION: Set distinct guid for mechanism for DwCEventDateTG2DQ. Java to 1.8 and added commons-lang3 in pom for StringUtils. Moved implementation for dateIdentified into DwCOtherDateDQ. Fix for single digit days and months being recognized as valid ISO date, updates to unit tests in consequence. DateUtils.extractInterval() and extractDate() now returns null when given single digit day or month values. Fix for handling of date ranges with end date before start date. DateUtils.eventDateValid() now returns false on these. added unit tests for validationYearEmpty, amendmentDayStandardized, amendmentEventdateStandardized, validationDateidentifiedNotstandard.
Updated Note based on recent discussions: If dwc:day contains text that may be interpreted as Roman numerals, the result will be "NOT_AMENDED" as this is not standard. Values such as "3rd" or "12th" can be interpreted as the integers "3" and "12". Text such as "5th Friday" is ambiguous. |
…sts to current specifications. DESCRIPTION: Updating implementation and fixing unit tests for AMENDMENT_MONTH_STANDARDIZED and AMENDMENT_DAY_STANDARDIZED to conform with current (2022-03-10) specification. Fixing return of Response.result from amendments to a empty map instead of null for easier handling by consumers of the method responses.
…t current (2023-06-04) test descriptions. Adding ProvidesVersion annotations. Removing now empty file stubs for checked methods. Addressed tdwg/bdq#127 AMENDMENT_DAY_STANDARDIZED and tdwg/bdq#128 AMENDMENT_MONTH_STANDARDIZED. Removing deprecated wrapper methods.
Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted". Also changed "Field" to "TestField", "Output Type" to "TestType" and updated "Specification Last Updated" |
The text was updated successfully, but these errors were encountered: