Compute the sum, the average, the min or the max of numbers in a collection. Typically, these function
takes the collection as the sole parameter. However, when the collection is a model element list, a second
parameter may be necessary to specify the name (in the form of a string) of the list entry's value property
to use in aggregation. If the the collection is a model element list and the second parameter is not
specified, these functions will use list entry's first value property for aggregation.

When a property is described to a user in documentation one does it with a series of short statements that
define its semantics, such as "must be specified" or "maximum value is 100". When a property is
described to Sapphire one does it with a series of annotations, such as @Required or
@NumericRange. This duplicate specification is a maintenance problem.

A FactsService provides a means to dynamically derive statements about property's semantics
based on property's metadata. The derived facts can then be presented to the user as part of documentation,
property editor information popup and in other relevant places.

The concept of deriving facts from metadata has existed in limited capacity in past releases.
New for 0.4 is formalization of this system via FactsService API that allows adopters to participate
in generation of facts on equal footing with the framework. Also new for 0.4 is a much longer list
of annotations that generate corresponding facts.

The InitialValueService produces a value to assign to a property when the containing model element is
created.

The concept of an initial value is different from a default value. The initial value is explicitly
assigned to the property during containing model element's creation. This includes writing to the backing resource
(such as an XML document). In comparison, the default value is used when null is read for a property from the
backing resource. As such, the default value is only visible to model consumers (such as the user interface),
while the initial value is persisted.

Whether you use an initial value or a default value is frequently dictated by the requirements of the
backing resource. As an example, let's consider an XML document that stores phone numbers. In this XML document,
the phone number element has a type child element which contains a value like home, mobile, work, etc.
Let's further say that semantically, we wish to use mobile phone number type unless specified differently.
Now, if the XML schema dictates that the phone number type element is required, we would need to specify
"mobile" as the initial value. If the phone number type element is optional, it would be better to specify
"mobile" as the default value.

The set of possible types for a list or an element property is usually static and as such can be
specified using @Type annotation. However, when the model needs to be extensible or the set of possible
types needs to vary due to runtime conditions, a custom PossibleTypesService implementation can now
be supplied.

The ContentProposalService provides a conduit for content assist in property editors. If a property
has this service, content assist will be automatically enabled in the property editor. The manner in which
content assist is presented is specific to the presentation, but usually involves a popup window with
proposals, activated by some combination of key strokes (such as CTRL+SPACE).

The framework provides an implementation of ContentProposalService for properties with @PossibleValues
annotation or a custom PossibleValuesService, but this service can also be implemented directly by
adopters.

The JavaTypeConstraintService describes constraints on the Java type that a property can reference, such as the kind of
type (class, interface, etc.) and the types that the type must extend or implement. The information provided by this
service is used for validation, content assist and other needs.

The framework provides an implementation of JavaTypeConstraintService for properties with @JavaTypeConstraint
annotation, but this service can also be implemented directly by adopters. This is particularly useful when Java
type constraint can vary at runtime.

Use available screen real estate more efficiently by splitting a form into two or more sections. The
sections can be arranged vertically or horizontally. The developer can specify the desired initial distribution of
available space among the sections and the provided sashes allow the user to adjust the space allocation
as necessary at runtime.

A split form can nest inside another split form. This is particularly useful when the two split forms
use different split orientation.

Example

In this example, a dialog is split vertically into two sections. The top section
holds a list property editor while the bottom section holds the editor for the description property linked to
the selection in the list property editor. The split form allows the user to control the amount of space allocated
to the list property editor versus the description text field.

The new @XmlDocumentType annotation can be used when working with DTD-based documents to easily specify systemId or
publicId/systemId pair. Sapphire XML binding will manage the XML DOCTYPE declaration.

The new @XmlSchema annotation can be used when working with XSD-based documents to easily specify schema location for a
given namespace. Sapphire XML binding will manage the xsi:schemaLocation declaration.

When declaratively specifying XML binding for a list or an element property, the adopter must tell the framework
what XML element name to use for a given child model element type. In the past, the only way to do that was via
the mappings attribute of @XmlListBinding or @XmlElementBinding annotation. These declarations can now be made
via @XmlBinding annotations placed on the model element type. If the property's mappings do not contain
a declaration for a given model element type, the framework will look for the type's @XmlBinding annotation.

Which approach you choose to use depends on the requirements. Explicitly specifying mappings is useful when
the same model element type is used in different properties where it must bind to different XML element names.
Using @XmlBinding on model element type instead of mappings is less verbose and is particularly useful in cases
where a custom PossibleTypesService is provided. In those situations, list or element property's author may
not be able to enumerate possible types at design time, so explicitly specifying mappings is not possible.