In the last post, I took up Grahame’s request for feedback on possible alternative syntax for extensions. To review, the goal would be to eliminate the use of the <extension> tag and use readable names, similar to the way core elements are represented. It may or may not be possible to improve on the current representation, but it is worth investigating. In the last post, I listed the following requirements:

1. The representation MUST support distributed extensibility.
2. The representation MUST distinguish modifying extensions from normal extensions.
3. The representation MUST allow the receiver to determine the identity of each extension.
4. The representation MUST allow parsing the URI, the value, and the data type of an extension without reference to the extension definition.
5. The representation MUST be able to express conformance of the resource instance to one or more structure definitions.
6. The representation MUST SHOULD be easily readable (changed from MUST to SHOULD as suggested by Josh Mandel because of the subjective nature of readability).
7. The representation SHOULD leverage existing standards.
8. The representation SHOULD leverage existing standards for schema validation.
9. The representation SHOULD treat extensions and core elements in the same way.

Let’s take stock of the current DSTU 2 representation in terms of these requirements:

1. Yes – Because each extension is identified by a URI, and there should be no naming collisions between extensions.
2. Yes – Modifying extensions are indicated by the <modifierExtension> tag.
3. Yes – The URIs of the extensions are part of the serialization.
4. Yes – The tag indicates the data type of the value for extensions, e.g. <valueString>,<valueReference>. [As a side note, the data type for elements defined in the base resource are not stated explicitly, so to interpret a value defined by a base resource you must either refer back to the resource definition, or build that knowledge into the parser.]
5. Yes and No – Every instance refers to the base resource definition. A resource can also provide links to other structure definition(s) in the resource metadata (meta.profile), but is not required to do so.
6. This is the base case we are trying to improve on. The wire format is not easily readable when there are numerous, nested extensions or structure definitions built on the Basic resource.
7. Yes and No – Uses the basic XML and JSON standards, but FHIR invents new standards and conventions on top of those standards (not necessarily bad).
8. Yes and No – Uses XSD and schematron on the XML side, but custom validation on the JSON side.
9. No – There are different sets of rules for expressing base elements and extensions

As expected, the current approach meets the essential requirements. The negatives are primarily the ones we are trying to overcome, i.e., needing different representations for “normal” elements and extension elements, and perhaps also, not using existing standards to the maximum degree.

What of Grahame’s alternatives? The following table shows how they stack up against the requirements.

• Option #1 adds a structure definition URL as an attribute on the root element, thus identifying the one source of extensions. This has several problems, mainly limiting the representation to one structure definition, and requiring the receiver to refer back to that definition to find information required to parse the payload. This approach would also be redundant with the current ability to list applicable structure definitions in the resource metadata (in Resource.meta.profile).
• Option #2, which provides URL for each named extension as an attribute of that extension, does not prevent naming collisions among the tags, because two extensions could use the same name. It also misuses the XML namespace technique.
• Option #3, which adds a preamble listing each extension name, its URL, and its data type, requires an iteration over the resource to be serialized, to collect all the extensions, before writing out the resource. It also suffers the same naming collision problem as Option #2, unless there was some additional strategy to deconflict extension names after they are collected. It also creates new set of XML conventions, something we would like to avoid.
• The ‘Final Option’ requires a central naming authority, and thus, fails the primary requirement of distributed extensibility.

So Grahame is correct that these four alternatives aren’t better than the current option. But, nonetheless, there might be other options out there.

Next time: Are there better options?