Fix issue with generation of CVR XML via export fragment.

Provide an XML Catalog file. Requires usnistgov/Voting#10 to be resolved first.

Establish a pipeline for validation of XSD / Schematron. Running into issues with Calabash. It does not seem to run Saxon-EE, or is not running the XPath rules that require schema-awareness, which leads to false negatives.

This thread is to describe current efforts to allow users to use free or open source software to use the prototypes developed so far.

• All Schematron rulesets require a schema-aware processor
• xml2json requires schema-aware processor, XSLT3
• json2xml requires XSLT3

AltovaXML Community Edition Version 2013 rel. 2 is the last known free, schema aware processor. However, it only supports XSLT2. Saxon supports XSLT3, but the open source version does not support the required fn:json-to-xml and fn:xml-to-json functions.

AltovaXML does not support extension methods in either Java or .NET.
It may be possible to write a pure XSLT polyfill for xml-to-json, then use AltovaXML to transform.

Update files to reference new namespaces

• update schematron files
• update xslts
• update remaining xml files
• update xdps

I'm a researcher using CVRs to study vote choice patterns. I'm looking for ways to translate CVR files into datasets that can be analyzed in e.g. R.

For example, San Francisco uploads their CVR as JSON files: https://sfelections.sfgov.org/november-3-2020-election-results-detailed-reports (See under Final Report, "Cast Vote Record (Raw data) - JSON"). Attached is an example JSON file.

How should I go about using the resources on this repo to read this in extract the entries I care about (e.g., precinct information and vectors of vote choice at each voter/ballot level).

CvrExport_24882.json.zip

Support for conditional disabling of overvote protection, for CVR generation

Support for OCL to Schematron could be based on work done by ShapeChange. However, their tooling only understands XMI 1.x files, which means that the code would have to reworked. Additionally, their code is based on GML application schemas, which is not the goal of our tooling. We would likely need to map MagicDraw to their models.

• Strip code out of ShapeChange needed for conversion
• Rewrite sections / map to MagicDraw constructs
• Map MDA stereotypes to control output
• Generate output

Another approach might be to create a MD extension, which implements the ShapeChange model classes, and use that to interface with shapechange.

See CDFConverter

• Documentation on principle of operation
• Documentation of EML subset (RCV features only)
• Review static PDF Boilerplate