Architectural Overview

This document will outline:

• core architectural choices made by the project team

  • General Project Architectural Decisions
    • Architectural Decisions will be recorded
    • No specific release strategy was recorded Unofficially the project attempted to release on a bi-weekly basis. However, the updated code was always available after merge to the 18F main repo.
    • Spock versioning was chosen as the versioning strategy.
    • [Project followed GSA TTS Recommendations on GitHub team organization](https://github.com/18F/fedramp-automation/blob/master/documents/adr/0003-github-management-teams.md.
    • Operational docs were stored in GitHub Wiki.
    • Collection of Usage Metrics was via DAP and Google Forms at various points in the project.
  • Code Specific Architectural Decisions
    • XML and Schematron - XML was originally chosen as basis of validations due to familiarity of NIST developers with XML technologies. This was continued throughout the project after review by 10X. This allowed easier integration with NIST toolchain.
    • The choice of Schematron for validation meant the requirement of an XSLT processor for transpilation. Several processors were evaluated. Saxon HE was chosen for widest usage and ease of itegration.
    • XSLT integration within Schematron was supported. This allowed for reduced learning curve by developers already familiar with XSLT and a reduce reliance on duplicated code within the Schematron.
    • Shell-based validation pipeline - The decision was made to focus on shell-based development as the needs of the community had not (and still have not) been fully expressed.
    • (XProc pipelining was investigated](https://github.com/18F/fedramp-automation/blob/master/src/validations/docs/adr/0006-evaluate-xproc-pipeline.md) - Ultimately the level of effort required was deemed outside the scope of the project and likely to interfere with FedRAMP validation development.
    • Client-side Validation user Interface was developed - Initially this was designed for proof of concept, internal testing, and display for FedRAMP reviewers' feedback. It evolved into use by 3PAO users for validation of their OSCAL deliverables prior to/during FedRAMP review.
    • Attachment validation policy is minimal - Due to complexity of inputs and considerable number of possible filetypes, attachment validation was mostly left to post-validation processes (as yet undefined) and manual review by FedRAMP reviewers as is current practice.
    • Multi-document Validation Rules - This was a major aspect of the Phase 4 work. Basic validations are available, based on existing FedRAMP OSCAL Guides, for the four types of OSCAL documents.
    • Remote Resources - available via XSLT param element
    • DNS Validation - available in schematron validation rules.

• high-level rationale with links to appropriate ADRs {Perhaps this was combined with the above?}

• potential considerations for future changes

  • SchXSLT Port to use of this for Schematron evaluation. Current transpilation tool is no longer being developed.
  • Saxon-EE integration This would allow for web based OSCAL Schema validation. Has a monetary cost and not tested for use with the current online tool.