Schema validation

[cmc333333]

I think there are three separate validations of differing complexity:

1. Ensuring input is actually JSON/XML/etc. - this should take place at the parser level and we won't need to write too much custom code
2. Ensure that all required fields are present and of the right type - this is part of the de-serializer. I expect we'll be able to crib quite a bit off the model serializers here.
3. Ensure the document follows the correct schema - this is the more interesting problem and will take more thought. This'd account for things like "ensure all sections have a title" or "tables should only have caption, thead, tbody children".

Aside from listing the components we haven't spent much time on the document schema (3). We might start with an XSD as a simple, document-oriented schema language; I'd argue it'd also be worth considering ProseMirror's schema structures and looking around for other standards we could share across the apps (we'll have a version of the schema in the editor, the api, and the ui, though probably encoded differently). I'd recommend against JSON Schema, as it's not document oriented. I'd also strongly encourage thinking about the policies as one type of document with the potential for more; it'd be forward thinking to lay a general foundation for schemas now.

[cmc333333]

Thinking of those phases in terms of types, it’d be:

1. Binary blob parsed into nested Python dicts (this takes place in DRF’s parsers)
2. Python dict fields validated and converted into Django models (this takes place in DRF’s serializers)
3. Django models are compared against a document schema and saved to the db (this would be a new thing)

[cmc333333]

Attempting to split this into specific tasks:

Parser level

• Ensure custom AKN importer handles invalid XML correctly - Likely resolved in #884

Serializer level

(Broken out here: https://github.com/18F/omb-eregs/issues/906)

• Check that DocNode fields are validated (required, character limits, etc.)
• Check that Inline/Annotation/Content fields are validated (required, character limits, etc.)
• Check if there are any input fields which aren't class-level, declarative, DRF Field classes. If so, we'll need to validate them, too.

Document Schema level

(Broken out here: https://github.com/18F/omb-eregs/issues/907)

• Select a tool to describe the schema for a policy. XSD, ProseMirror schema, etc.
• Encode a (flexible) document schema in that tool.
• Write utility to compare a DocCursor against that schema.
• Run that over all our imported docs to ensure they conform. Where they don't, create an issue for us to tackle later.
• Use that tool in the PUT endpoints of the API; ensure failures messages are returned and displayed.

[tadhg-ohiggins]

Closing because this was covered by #884 , #906 and # 907 (thanks @cmc333333 !)