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 solutions

No concrete proposals, open for discussion.

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