This page is a subpage of CMDI 1.2

Extended display information

The issue

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 notable exception of the displayPriority attribute, which has not proven to be a very popular or well understood feature). It would be desirable to have some unified (and preferably extensible) way of providing (sets of) display cues related to but physically separate from the description of the logical structure - think of a model like (conceptually) CSS and XML, although the display information should probably go beyond styling (otherwise plain CSS might as well be used).

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.

Open questions:

• Where to store this information? (In the profile/schema, in a separate file linked from the profile/schema?)
• Will we allow multiple sets per profile for different scenarios (like CSS)?
• How will this information be generated and by whom? (Part of component registry/separate editor,separate registry?)

Proposed solution

A separate namespace is used for display cues (e.g. ​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 (for an example, see below).

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.

Notes:

• The style should probably inject the namespace definition and schema location into the component spec so that we can have 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'
• Maybe we want to have several 'sub-namespaces' for different kinds of cues (e.g. editor cues, viewer cues, ...)
• If we would do it like this, there will be a demand for a style editor because modellers are not going to want to write XSLT's (and we probably don't want them to)
• The 'style registry' could be integrated with the Component Registry though.

Pros

Pros of this solution

Cons

Cons of this solution

Centre impact

• Affected tools
  • Infrastructure
    • Component Registry
  • Editors
    • Arbil
    • ProForma?
  • Viewers
    • VLO
    • ...
• Impact on instances

Implementation examples

Cues will be represented on the model level only (component specification -> XSD), not on the instance level

Implementation on model level

Allowing any attribute in the cues namespace on components, elements and attributes (or maybe different namespaces).

A simple case:

    <CMD_Element name="Title" />

can be transformed to

    <CMD_Element name="Title" display:backgroundcolor="#"/>

Visual merging of (linked) child components (only effective if child component does not have repeating children):

    <CMD_Component name="ActorLanguage">
       <!-- link to ISO-639-3 component -->
       <CMD_Component  ComponentId="clarin.eu:cr1:c_1271859438110" CardinalityMin="1" CardinalityMax="1" display:mergewithparent="true" />
       <CMD_Element name="PrimaryLanguage" />
    </CMD_Component>

An alternative to the display priority attribute of CMDI 1.1:

    <CMD_Component name="Actor" display:salientelements="Name,Role">
       <CMD_Element name="Name" />
       <CMD_Element name="Role" />
       <CMD_Element name="Age" />
    </CMD_Component>

Tickets

Tickets in the CMDI 1.2 milestone with the keyword displayinformation:

Ticket	Summary	Owner	Component	Priority	Status
#139	addition of an importance attribute	Dieter Van Uytvanck	ComponentSchema	minor	closed

Discussion

Oddrun: I for one think it's a great idea to provide more display information! To the open questions:

• Where to store the information? NOT in the component/profile specification! One strong reason for this is that changes in display information should not be allowed to affect (complicate) the versioning of the profile. One idea could be to extend the CMDI metamodel with the class DisplayComponent?, each instance of which specifying one display configuration of one specific component, and stored in a separate registry. A "display configuration" could be along the lines mentioned above (grouping of elements/profiles, salient elements/components)

• Yes, multiple display configurations should be allowed per component/profile.
• Metadata modellers and tool developers should generate such display configurations. Metadata modelers at component-design-time (sort of "default display"). Tool developers could pick and choose from existing display configurations, and generate his own. At profile level, there will probably be a need to generate some kind of stylesheet based on the selected display configurations?

Discuss the topic in general below this point