...
(6) Unlicensed user, please check to make sure key/value pairs can be handled in both JSON and XML. See (8) and (9) below.
Second thoughts
(7) I'm thinking that rather than being subclass handlers, all 3 definitions and all 3 requests should be first-class resources. They would each contain all the current superclass fields (except Type) plus their own private fields. That way, we could at some later point incorporate their subclasses (e.g. AgeCohortDefinition, EncounterDatasetDefinition, PeriodIndicatorReportDefinition) into the model so they can be CRUDed through the REST interface.
(8) Re key-value pairs and (6) above, I am thinking that DatasetDefintions[] and Datasets[] can be represented as arrays of links, with the "rel" field being the key and the "uri" field being the uri of the resource.
(9) See the new note in the diagram about ColumnNames[]. DataRows[] can be as Darius proposes unless this causes some problem, in which case we should drop the column names and require that all rows have values for all columns. I fear that many datasets will be sparse, resulting in many NULLs, but that may be best for JSON. It is possible that the XML version may differ.