Skip to content

Latest commit

 

History

History
105 lines (72 loc) · 6.55 KB

TODO.md

File metadata and controls

105 lines (72 loc) · 6.55 KB

TODOs

  • move most of default config to pkg fokus

  • implement target iterators handling

  • during qstnr assembly, ensure that

    • targets doesn't include anything else if "none" is present.

    • values is not empty in the end (the schema neither demands values nor value_scale).

    • all values subkeys are of the same length (JSON Schema unfortunately doesn't provide any means to do such validation).

      qstnr::unnest_qstnr_vals() ensures this implicitly and throws a moderately meaningful error in case of a violation à la:

      ! In row 575, can't recycle input of size 2 to size 3.

    • if values and value_sets are provided, the latter contains "values" (we can't do that in the schema (yet) since the contains keyword was only added with draft 6).

    • iterators are sensible. the schema only demands an array of arrays -- technically anything could be in those level-2 arrays...

  • Taplo uses jsonschema-rs under the hood which (as of 2023-11) supports JSON Schema up to Draft 7, so we should be able to use more than just Draft 4 features... -> test this!

    Furthermore, jsonschema-rs already partially supports the JSON Schema Drafts 2019-09 and 2020-12. Once tamasfe/taplo#498 is merged (or Taplo has switched to boon instead), we should be able to use (supported) features from these newer JSON Schema Drafts and consider porting our schemas to the latest draft iteration.

  • write documentation

    • general questionnaire principles
      • all vars that have translatable values must also have values.int defined (in order for as_int_vals target filters to work)
    • schema restrictions, rules etc.
      • allowed characters for footnote ids are based on the MDN recommendations found in the id attribute article (starting with numbers is allowed since the markdown processors usually prepend the ids with a string like fn- anyways)
      • allowed characters for link ids ("labels" in Pandoc terminology): @ is forbidden to prevent clashes with citation keys (which take parsing precedence)
      • iterators defined via the i array are referrable in inline R code by appending the iterator index (starting by 1 as it is the convention for vectors in R), i.e. the first iterator is i1, the second i2 etc.

  • submit schemas to JSON Schema Store? cf. https://taplo.tamasfe.dev/configuration/developing-schemas.html#publishing

  • publish stable release

    • replace all occurrences of https://qstnr.rpkg.dev/dev/ with https://qstnr.rpkg.dev/ in schemas (and elsewhere) -> change default to schema_url(dev = FALSE) thanks to our HTTP redirects we can actually do this already!
    • submit to CRAN

  • further investigate shortcomings of taplo's schema validation

    e.g. adding a forbidden survey config key qstnr.introo doesn't trigger a validation error in taplo (compare with this online validator which properly errors)

  • implement fns to write TOML. requires an R package providing support for this since RcppTOML only offers read support. we could write an R package that offers taplo or toml crate bindings; relevant resources:

  • Have a look at the following R packages and check whether we should take inspiration from them:

  • integrate with suitable open-source survey "servers". candidates include:

    • LimeSurvey 6

      • still sucks massively: PHP app based on LAMP stack; terrible community both in technical and organizational terms; awful dev experience due to basically unusable/undocumented APIs)
      • to sum up: LimeSurvey has design flaws beyond repairability and is not intended to be used by programmers but only targets non-programmatic usage

    • Formbricks!

      • offers REST APIs incl. the management API's survey sub-API that i.a. offers an endpoint to create surveys; this might not be enough for our use case, though (create the whole survey (incl. routing and everything) from data submitted via API)
      • development is very active and fast, but currently Formbricks still lacks a few mandatory features I think -> need to thoroughly investigate/test!

    • see this short overview for 3 more OSS projects (of which none matches what we want 😐)

Should we build some kind of formr integration? qstnr's functionality would probably be a perfect fit...

fundamentals

  • make value_sets part "directionless" by

    • always sorting the definitions ascendingly, allow new sentinel desc: in value_sets
    • implementing desc: interpretation
    • communicating new requirement/guarantee in doc
    • validating new requirement in code!

  • implement some kind of sentinel (like free_text:) to signify free text fields? (label would follow)

  • should we introduce another item key values_ptype (or the like) to specify what we first wanted via values = "{ val_ptype(type = date, size = 1L) }" (which the schema doesn't allow anymore)? or come up with a better/proper syntax for value validation, depending on ptype (to e.g. ensure a date lies in between a specific range), i.e. maybe directly use checkmate?