-
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 - Link to Specification Source Code #165
Comments
I think that was discussed at one point (I've only recently taken over our participation in this effort) and the feeling was that it'd be more direct to write a primary implementation in one language with any additional languages using that as a reference. I'd let @ArthurChapman or @chicoreus weigh in though. |
@ianengelbrecht, yes it would be of great value to add a pseudocode specification to each test. The TG1 framework includes an element for specification that could contain this, we haven't yet actually framed such a specification for any of the tests, and pseudocode would be a very good way to do this. |
To be more explicit: "Specification" has a formal meaning in the TG1 framework. A validation method, measurement method, and enhancement method (and problem method) all compose a specification with a (dimension,criterion,enhancement) in context. Where what we have specified so far in the TG2 test descriptions is at the level of dimension/criterion/enhancement in context. Adding a specification to an X in context moves from the description of general concepts to the level of data quality solutions. See the TG1 Framework Cheat Sheet in the wiki. |
@chicoreus @Tasilee I am wondering if using pseudocode (with links to actual implementations) would be suitable for a TDWG Best Current Practices Document to document the tests? Just a thought |
As previously raised, I think it may be expedient to use @chicoreus code as the base due it being largely done. In theory, pseudocode would be nice and this was the original idea. |
Hi all, thanks for the opportunity to participate. In line with @mjcollin's initiative to develop implementation libraries (#150), would it be of any value to include pseudocode in the specification table for each test rather than a link to a specific implementation? As I understand it we're hoping to develop in a number of languages so it might be good to have a common pseudocode reference to use.
The text was updated successfully, but these errors were encountered: