This page documents how the content of the resources are described. In actual exchange, resources can be represented in the following formats: XML and JSON. Other representations are allowed, but are not described by this specification.
The resources are described in several different ways:
In addition to this descriptive syntax, other definitional forms are available, including W3C schema and Schematron, and the StructureDefinition syntax defined internally.
The Logical View shows the resources as a tree structure with the following columns:
|Name||The name of the element in the resource (manifests as XML element name, or JSON property name. Some names finish with "[x]" - the meaning of this is discussed below. In addition, this column contains an icon that denotes the underlying type of the content. The icons are described below|
|Flags||A set of information about the element that impacts how implementers handle them. The flags are described below|
|Card.||The lower and upper bounds on how many times this element is allowed to appear in the resource|
|Type||The type of the element (hyperlinked to the definition of the type)|
|Description & Constraints||A description of the element, and details about constraints that are applied to it. Particularly, for coded elements, information about which codes can be used|
Here's an example:
|Name||Flags||Card.||Type||Description & Constraints|
|Resource Name||Base Type||Definition|
|nameA||Σ||1..1||type||description of content|
SHALL at least have a value
Key to Type Icons and Flags
A few elements have a choice of more than one type for their content. All such elements have a name that takes the form nnn[x]. The "nnn" part of the name is constant, and the [x] is replaced with the title-cased name of the type that is actually used. The table view shows each of these names explicitly.
All elements that have a choice of data type have a maximum cardinality of 1. There can only be one element for type, of one of the allowed data types.
Note: In object-orientated based implementations, this is naturally represented as a polymorphic property. However this is not necessary, and the correct implementation varies according to the particular features of the language. In XML schema, these become an xs:choice of element.
The UML diagrams represent the same content as a series of classes that represent the elements of a resource.
Where an element can have a choice of data types, these are represented by listing the type names separated by the "|" character. The elements and types are links to the formal definitions of the parts. The UML diagrams also show the bindings, and these are hyperlinks to the value set details.
These UML diagrams are intended to communicate the contents of the resource to a human, and are not suitable for code generation using standard UML code generation tools (see the eCore reference implementation for UML related code generation).
The actual order of the elements in XML cannot be determined from the diagram, nor whether a UML property becomes an element or an attribute.
This specification defines these ways to represent resources when they are exchanged:
Clients and servers can choose whether to implement in XML or JSON. In the interests of interoperability, Servers SHOULD support both formats. Systems SHALL declare which format(s) they support in their Conformance Statement. If a server receives a request for its conformance statement in a format it does not otherwise support, it SHALL return a 415 Unsupported Media Type.