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 contain very little dedicated information about how information contained in instances should be presented. 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 as with (conceptually) CSS and XML.

Display aspects might include grouping and merging information, salient element selection (as an alternative to 'displayPriority') and an indication of importance beyond cardinality.

Description of proposed solution

A separate namespace will be used for display cues. In this namespace attributes are defined (in a separate 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. This workflow is sketched in the diagram below.

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

Note that different versions of the style 'language' can potentially exist and tools can support one or more (subsets) of these variations.

General Component 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 (assuming the attribute definition gets normalised)

• <xs:anyAttribute namespace="http://www.clarin.eu/cmdi/cues/display/1.0" processContents="strict"/>

Profile schema changes

The display cue attributes are transformed into ​xs:appinfo elements below 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 parameter ('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)