-
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-VALIDATION_BASISOFRECORD_NOTEMPTY #58
Comments
Comment by Lee Belbin (@Tasilee) migrated from spreadsheet: |
Agreed at TDWG 2018 DQIG meeting that the test is a Validation and the name TG2-VALIDATION_BASISOFRECORD_EMPTY is satisfactory. |
Generating test data for this and wonder if we should have an 'INTERNAL_PREREQUISITES_NOTMET if dwc:basisOfRecord is not provided'? My feeling is "no" as this would be equivalent to EMPTY? |
Agreed @Tasilee |
@Tasilee I concur. To allow for implementations where the test is unable to tell if the field was provided as a data element for a record or not, we've included term not provided within the definition of empty, so tests should simply specify what state should be returned for empty and not separately make an assertion about a term not being provided. |
Going through the test data, dwc:basisOfRecord="[non-printing characters]" with the current Expected Response would suggest to me to return "COMPLIANT": A sort of false positive (which is sort of ok :). Are we happy with that or are we suggesting something like "interpreted as a text string"...or similar? I want to keep this simple. |
With all the "[non-printing characters]" we have treated them as EMPTY (and therefore NON_COMPLIANT) - we have been consistent - I guess it is because a human can't see them - they don't print. They would be easy to fix if we change that as they are all treated exactly the same in the EMPTY/NOT_EMPTY tests. This is different to "[Null]" where there is something - like "-n/", "null", "NULL", "9999", etc. where this a value and thus it is NOT_EMPTY and thus COMPLIANT |
I prefer to keep them as EMPTY.
…On Tue, Mar 1, 2022 at 11:53 PM Arthur Chapman ***@***.***> wrote:
With all the "[non-printing characters]" we have treated them as EMPTY
(and therefore NON_COMPLIANT) - we have been consistent - I guess it is
because a human can't see them - they don't print. They would be easy to
fix if we change that as they are all treated exactly the same in the
EMPTY/NOT_EMPTY tests. This is different to "[Null]" where there is
something - like "-n/", "null", "NULL", "9999", etc. where this a value and
thus it is NOT_EMPTY and thus COMPLIANT
—
Reply to this email directly, view it on GitHub
<#58 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADQ722SYOPTQGN374CRLUDU53J2NANCNFSM4EKSMW6Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
…nimal unit tests for those tests. Implementations for tdwg/bdq#94 tdwg/bdq#58 tdwg/bdq#103 tdwg/bdq#99 tdwg/bdq#47 and tdwg/bdq#117 added utility class with method to test if empty. Changing implemented methods to static.
Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted". Also changed "Field" to "TestField" and "Output Type" to "TestType". |
The text was updated successfully, but these errors were encountered: