This page is a subpage of [[CMDI 1.2]]

= Display Information in CMDI 1.2: Executive summary =

This page provides an executive summary of the issue and proposed solution fully described in [[CMDI 1.2/Cues/Display information]].

== Issue description ==

CMDI profiles provide the blueprint for a logical structuring of metadata instances. They provide very little information about ''how'' the information contained in the records should be presented (with the exception of the ''displayPriority'' attribute). It would be desirable to have some unified and extensible way of providing (sets of) display cues related to but physically separate from the description of the logical structure like (conceptually) CSS and XML.

Display aspects that might be included:

* Grouping information 
 * Grouping of elements within components
 * Merging of components on one level
 * Merging of components contained within one other
* Salient element selection - an alternative/replacement for display priorities allowing the client to select one or  elements representing the component in which they are contained for summarised display (e.g. in a tree). Logic might be more sophisticated than a single priority number.
* Field display mode reflecting importance

== Description of proposed solution ==

A '''separate namespace''' is used for display cues (http://www.clarin.eu/cmdi/cues/display/1.0). In this namespace attributes are defined (in an independent XSD) for all kinds of display and interaction cues.
The general component specification allows any attributes from this namespace on all components, elements and attributes. To define a 'style' for a given component or profile, an '''XSLT''' stylesheet has to be created that '''augments''' the component specification with these cue attributes with the desired values.

The component-to-schema XSLT picks up all cues and wraps them in app info blocks in the profile XSD. When requesting a profile from the Component Registry, it can be instructed to apply a style (or maybe multiple), e.g. by getting ''/registry/profiles/clarin.eu:cr1:p_1361876010587/xsd?style=my_style'' where ''my_style'' is an identifier that gets the style from some '''style registry'''.

[[Image(extended display info.png)]]

Notes:
* The style injects the namespace definition and schema location into the component spec which allows independent versioning of styles
* Applications can choose which cues to support and which not, and will also likely support a specific version of the style 'language'

The required '''infrastructure''' extensions will be developed at a later stage and is not part of the CMDI 1.2 specification. 


=== Schema changes ===

The following changes to the General Component Schema are proposed:

New xs:anyAttribute with namespace "http://www.clarin.eu/cmdi/cues/display/1.0" for ''clarin_element_attributes'', ''clarin_component_attributes'' and ''Attribute'' (? TODO):
* <xs:anyAttribute namespace="http://www.clarin.eu/cmdi/cues/display/1.0" processContents="strict"/>

=== Profile schema changes ===

The display cue attributes are inherited on the element and attributes definitions in the schema file.

=== Instance changes ===

There will be no changes to CMDI instances. 

=== Impact on tools ===
There is no impact on tools as long as there is no agreement on details which are not part of this specification (about what kind of display information will be used/supported). If there is such an agreement the following changes would be necessary:


* Extension of the Component Registry with some kind of 'style registry' and "style editor'
* Extension of the Component Registry API with additional attribute ('style') to activate the augmentation of the component specification with style information 
* Metadata editors and all CMDI viewers (like the VLO) may use this information for enhanced display (and may decide to use only a subset)