-
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_EVENTDATE_STANDARDIZED #61
Comments
Comment by Lee Belbin (@Tasilee) migrated from spreadsheet: |
event_date_qc has a test with a guid 134c7b4f-1261-41ec-acb5-69cd4bc8556f referencing EVENTDATE_FORMAT_CORRECTION, need to confirm the correct GUID for this test. |
I don't agree with the note. "1999-11" and "1999-11-01/1999-11-31" are both valid ISO formatted dates representing the interval of time of November 1999. They have identical meanings, and are not different representations of precision (at least as far as I've been able to tell from the publicly available information on the ISO standard. |
Specification needs to describe how to handle ambiguity. 02/03/1884 is an ambiguous date and result should include a result state of AMBIGUOUS when providing an ISO format for such values, or the specification should provide limits on what forms of date are to be conformed with the ISO standard. |
As in the note I left at #86 to change the Tests Prerequisites to read ""The field dwc:eventDate is not EMPTY and is unambiguously interpretable as an ISO 8601:2004(E) date" |
I agree with @ArthurChapman and again note we need to consider responses from tests (as note in #86) |
…dwg/bdq#84 tdwg/bdq#26 tdwg/bdq#130 tdwg/bdq#61 PURPOSE: Updating tests to reflect updates in definitions and latest discussion in tdwg/bdq issues. DESCRIPTION: Removing confirmed unused isMonthInRange() method. Updating VALIDATION_STARTDAYOFYEAR_OUTOFRANGE to match new specification. Switching from #141 to #84 to test year for valid range. Correcting handling of ambiguity in AMENDMENT_EVENTDATE_STANDARDIZED and AMENDMENT_DATEIDENTIFIED_STANDARDIZED to conform with specifications.
…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.
… specifications. DESCRIPTION: Updating implementation and fixing unit test for AMENDMENT_EVENTDATE_STANDARDIZED to conform with current (2022-03-10) specification.
… specifications. DESCRIPTION: Fixing error in unit tests and in implementation of AMENDMENT_EVENTDATE_STANDARDIZED current specification is that internal prerequisites not met is only returned for an empty eventDate, but this was returned for other cases, as detected by running against the validation data.
"Original was "unambiguously conform..." while I think it should read "AMENDED if the value of dwc:eventDate was changed to conform to an unambiguous valid ISO 8601-1:2019 date.." |
I think the formulation "unambiguously conform" is correct, it tells the implementer that the act of making the data conform needs to unambiguously produce a single result, while the "unambiguous valid" simply reads as redundant for "valid", and and is saying that the result must unambiguously be a valid date, rather than saying that if there is the potential for more than one valid result, that path can't be taken. |
An ISO value can't be ambiguous can it? I think "unambiguously conform..." is OK |
OK, done |
Due to recent discussions, I have changed INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it can be unambiguously conformed to bdq:sourceAuthority; otherwise NOT_AMENDED to INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it can be unambiguously conformed to ISO 8601-1:2019; otherwise NOT_AMENDED ...and removed the reference to bdq:sourceAuthority |
Again picky, but I would say: INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it can be unambiguously transformed to ISO 8601-1:2019; otherwise NOT_AMENDED |
Edited accordingly |
I've edited the Expected Response according to @tucotuco suggestion: From INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it can be unambiguously transformed to ISO 8601-1:2019; otherwise NOT_AMENDED to INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it was unambiguously formatted as a valid ISO 8601-1 date; otherwise NOT_AMENDED | and updated the References |
See my comment under #26 Would the following be better? INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it was unambiguous by formatting as a valid ISO 8601-1 date; otherwise NOT_AMENDED |
I have updated the Expected Response as suggested above and the ISO Reference. |
I think the Expected Response should be similar to #26 i.e. INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it was unambiguous and formatted as a valid ISO 8601-1 date; otherwise NOT_AMENDED |
Like #26 the language has become unclear for implementors: "AMENDED the value of dwc:eventDate if it was unambiguous and formatted as a valid ISO 8601-1 date" is read as formatted meaning "was already in the form", not meaning that it was changed. We need to revert to language from a prior version that is explicit about AMENDED being when the data are changed. Propose changing from: "INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it was unambiguous and formatted as a valid ISO 8601-1 date; otherwise NOT_AMENDED" To: "INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it was not a properly formatted ISO 8601-1 date but was unambiguous and was altered to be a valid ISO 8601-1 date; otherwise NOT_AMENDED" |
Both here and in #26 we want to amend if:
|
…6-09) test descriptions. Adding ProvidesVersion annotations. Removing now empty file stubs for checked methods. Removed deprecated wrapper for method. Addressed tdwg/bdq#61 AMENDMENT_EVENTDATE_STANDARDIZED. Noted that like tdwg/bdq#26 the specification needs work to clarify the intent.
Again, I think the Expected Response may be clearer if your "INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it was not a properly formatted ISO 8601-1 date but was unambiguous and was altered to be a valid ISO 8601-1 date; otherwise NOT_AMENDED" is rendered as "INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it was not a properly formatted ISO 8601-1 date but was unambiguously interpreted as a valid ISO 8601-1 date; otherwise NOT_AMENDED" |
In line with #26, altered Expected response from INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED the value of dwc:eventDate if it was unambiguous and formatted as a valid ISO 8601-1 date; otherwise NOT_AMENDED to INTERNAL_PREREQUISITES_NOT_MET if dwc:eventDate is EMPTY; AMENDED if the value of dwc:eventDate was not a properly formatted ISO 8601-1 date but was unambiguous, and was altered to be a valid ISO 8601-1 date; otherwise NOT_AMENDED |
…specifications (2023-06-23). Updating implementation of tdwg/bdq#61 AMENDMENT_EVENTDATE_STANDARDIZED and tdwg/bdq#26 specification and metadata changed to be consistent with current behavior of code.
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: