Currently Prism Schema is defined in XML Schema Defenition (XSD) language with custom annotations (but that may change in the future).
On One of the unique features of prism is support for runtime and dynamic schemas.
Runtime schema is a static schema definition that is not available at compile time. It may be available as at assembly time or even at runtime. It usually takes form of XSD files that are loaded at system start. As such schema is not available as at compile time it cannot be used to generate compiled code. But except for that the runtime schema behaves almost the same as compile time schema: it is used to parse and validate data when parsing prism items from XML, to serialize data, etc.
Dynamic schema is schema that is not fixed, not even in runtime. E.g. there may be a container that can store items of any type, even each instance of the container may have different items of different types. Prism supports such schema and still correctly maintains definitions for such items end-to-end. E.g. it parses the data from the source format and creates appropriate definition. The definition travels with the item though through the system. If the data are serialized, the definition is serialized with the data (if possible), e.g. by using the XML
xsi:type runtime type specification.
Dynamic schema is tricky. Complete schema may not be available at the time that the data are parsed. Therefore prism allows dynamic items to be in the raw parsing state. It means that prism only parses basic data structure but the data are left as they were in the source file. E.g. when parsing data from XML prism determines what is a property and what is container but the actual data types are not yet determined. All the dynamic data remain internally in prism objects in the form of un-parsed DOM elements until the proper schema is applied. When the schema is applied the parsing is completed and the data are converted from the raw elements to the proper native data types. This process is mostly transparent to the user but there may be some gotchas (e.g. comparing parsed and raw items).
Prism data structures are designed to be extensible while also maintain a reasonable degree of backward compatibility. The primary mechanism to allow this is namespacing. Name and type of every prism item is a QName (name in a namespace). data formats that nativelly natively support QNames (such as XML) can take natural advantage of that. For simpler data formats (such as JSON) we create a dialect for prism data. Namespaces provide isolation of custom extensions from various sources and also isolate the extensions form a future evolutionary changes in primary prism data model. Namespaces also provide data model versioning: change in the primary namespace indicated non-compatible change.
Most prism classes implement the
clone() method, therefore the prism data objects are easily clonnablecloneable.
Prism items, values and definitions are
Serializable. However, there is a catch. Prism context is not serializable and it is a
transient member of prism items and definitions. Therefore deserialized prism items and definitions may not be fully operational. The call to
revive(...) method is required after deserialization to make the prisms work as expected.