Skip to content

CAWI JS modules - WIP

cawi-language

  • Wraps C programs to expose cawic executable (= xcawi DSC parser), which outputs _.xml file.
  • Exposes cawi2json executable to convert _.xml file into a JSON file (called project.json).
  • This JSON describes the PROLOG, DEFINITIONS, QUESTIONS, VARIABLES and WEIGHTS sections of the DSC.
  • Does routing is another JSON file or a a set of JS functions (like in CAPMI) ?

NOTE: Technically "cawic" is what's called a "compiler front-end" - stopping at the intermedite code generation step (the _xml contents), but performing lexical analysis (parsing), syntax analysis and semantic analysis.

cawi-engine

  • Is a library, i.e a set of functions (implemented as Javascript classes), which doesn't directly expose any executable or service.
  • Loads project.json + routing + interview data in view to deliver a page description as JSON (that we can call page.json even if doesn't exist as a file).
  • Exposes an "interviewing API" which can be deployed server-side (see cawi-server) OR client-side (CAPI).

cawi-server

  • Wraps cawi-engine.
  • Exposes services through an API (+ Swagger documentation) => get/post interview data, get project's schema (i.e project.json content), etc.
  • Handle authentication (in a new way but related with current "ACCESSMODEs").
  • Can handle CAPI synchronization too ? (maybe wrapping another capi-sync module ?)

cawi-storage

  • An interface for save() and load() methods that covers several storage methods for interviews (browser localstorage, server SQL or no-SQL database, or even files).
  • Implementation modules : capi-localstorage, cawi-db-storage or even cawi-file-storage.
  • Storage solutions based on JSON.
  • Database storage solutions behind an ORM.

cawi-*-ui a.k.a "cawi-display"

  • A familly of web UI modules, e.g cawi-std-ui, cawi-chat-ui, etc.
  • Will use a framework (or theoriticaly several ones) in view to organise its content into smaller pieces = reactives components.
  • Can call an API at some stage in view to receive a page description (see page.json).
  • Displays a web UI based on the page description and allows user input.
  • Can call an API at some stage to send data, after each page (standard CAWI) or later through a sync process (CAPI).

cawi-*-proxy

  • A familly of modules to interface with external APIs (like Twilio), e.g cawi-rcs-proxy, cawi-whatsapp-proxy, etc.
  • Two-ways proxies that receive input from external service then relay it to cawi-engine.
  • Wrapped by cawi-server (?)
  • A bit similar to "cawi-display" modules, but without UI, since they deal with the page.json response from the engine, then transform it into instructions to the external API.

Older description (from Dave):

Module overview

This is just a draft list of potential modules and their purposes. The exact split of modules and the interfaces between them will be defined (and probably redefined) during the development process.

  • cawi-language - will consist of the existing "xcawi" parser from XCAWI2 which converts the DSC file into an XML file, plus new tools to generate the standardised JSON formats based on that XML.

  • cawi-engine - the core runtime, able to be run on the server (replacing XCAWI2) or on the client (replacing CAPMI). This will use the standard JSON version of the DEFINITIONS and QUESTIONS section internally. The engine creates a standard JSON description of a page to be displayed, which is passed to a display module for rendering. The engine will be able to run the "route" of the survey in different modes - interviewing, cleaning/recoding, data generation (SIG) and printing.

  • cawi-display - the replacement for the "qask" part of XCAWI2 and CAPMI. This will take a JSON page description, which will include question definitions in the standard "_.xml" JSON format and render the page (in HTML or other formats, as appropriate). We will potentially have additional specialised display modules - e.g. for SMS/Whatsapp chatbots or client-specific HTML displays (e.g. the gov.uk standard). Rendering may be server-side or client-side, or a combination of the two.

  • cawi-app - the front-end application incorporating the node http server that deals with things like respondent access control, data pre-population and implementing the glue between the engine and display modules. Whilst this app is intended to be generic and used unmodified for most surveys, it could be adapted or replaced for more complex projects, allowing a complex data collection web application to be built around the core CAWI modules.

  • capmi-app - the equivalent to cawi-app for the CAPMI. An open question is the split (if any) between this module and the "tablet management module" - the app that the interviewer uses to manage the interviews.

We may want additional library modules that sit between the engine/display modules and the apps (e.g. for things like access control) - this will become clearer during development.