Changes between Version 237 and Version 238 of CMDI 1.2/Specification

Timestamp:

10/04/16 11:58:28 (8 years ago)

Author:

Twan Goosen

Comment:

CCSL section c'td

CMDI 1.2/Specification

@@ -805 +805 @@
 
 == Cue attributes ==
-{'''TODO''': Convery broader potential/scope of cues, not just (visual) presentation, illustrate with use cases}
-CMDI profiles provide the blueprint for a logical structuring of metadata instances. However, they provide very little explicit information about how the information contained in CMDI instances should be presented. Such information can be processed by viewers, editors and catalogues alike, leading to a potentially more uniform (across applications), visually pleasing and user friendly presentation of metadata. The usage of display information `SHOULD` always be optional for applications processing CMDI instances.
-
-For this purpose, all CMD attribute, element, and component specifications `MAY` contain additional attributes in the cue namespace. These `MAY` be used to give information about how the payload contained in the respective part of the CMD instance should be presented. Cues are grouped in component specific styles. Different styles for the same CMD component `MAY` be developed. The CCSL does not prescribe or suggest a specific set of cue attributes.
+CMDI profiles provide the blueprint for a logical structuring of metadata instances. However, they provide very little explicit information about how the information contained or to be entered in CMDI instances should be dealt with in applications that process or generate metadata documents. CMDI 1.2 therefore allows for the augmentation of components, elements and attributes in profile definitions with ‘cues for tools’ that provide suggestions for the way metadata content could be presented (e.g. by specifying certain typographical characteristics or specifying a set of elements that can be grouped together visually) or handled in some other way (e.g. enabling or disabling spell checking or using a specific input method).
+
+Such information, to be processed by viewers, editors and catalogues alike, has the potential of leading to a more uniform (across applications), visually pleasing and user friendly mode of working with metadata. The usage of such cues `SHOULD` always be optional for applications processing CMDI instances.
+
+For this purpose, all CMD attribute, element, and component specifications `MAY` contain additional attributes in the cue namespace. These MAY be used to give information about how the payload contained in the respective part of the CMD instance should be presented. Cues are grouped in component specific styles. Different styles for the same CMD component `MAY` be developed. The CCSL does not prescribe or suggest a specific set of cue attributes.
 
 Examples of aspects for which display cues may be introduced are display order, structural transformation (e.g. folding of hierarchies), labeling and visual styling.
 
-=== Example 17 Cue for CMD element ===
-
-This example shows a cue for a CMD element, i.e., its display priority within its component and a label which can be used when multiple instantiations are shown together.
+=== Example 18 Cue for CMD element ===
+
+This example shows a cue for a CMD element, i.e., its display priority within its component and a label which can be used when multiple instantiations are shown together. Note that this is a hypothetical cue that is not necessarily supported by any specific applications.
 
 {{{
 #!xml
 <Element
-  name="Name"
-  ...
-  cue:DisplayPriority="1"
-  cue:PluralLabel="Names"
+   name="Name"
+   ...
+   cue:DisplayPriority="1"
+   cue:PluralLabel="Names" >
+   ...
+</Element>
 >
-...
-</Element>
-}}}
-=== Example 18 Cue for CMD component ===
+}}}
+
+=== Example 19 Cue for CMD component ===
+This example shows two potential cues for CMD components: one cue specifying an ordered preference for the display value of the “Person” component, and another cue for the “Address” component to indicate that its contents should be shown at the same level as its parent’s contents. Note that these are a hypothetical cues that are not necessarily supported by any specific applications.
+
 {{{#!xml 
 <Component name="Person"
-  cue:LabelElement="Name,Initials,Id ">
-    <Element name="Name" CardinalityMin ="0" />
-    <Element name="Initials" CardinalityMin ="0" />
-    <Element name="Id" CardinalityMin ="0" />
-    <Component name="Address" CardinalityMin ="0" CardinalityMax ="1"
-      cue:DisplayInline="true ">
-        <Element name="Street" />
-        <Element name="Place" />
-        <Element name="Country" />
-    </Component>
-</Component>
+   cue:LabelElement="Name,Initials,Id ">
+     <Element name="Name" CardinalityMin ="0" />
+     <Element name="Initials" CardinalityMin ="0" />
+     <Element name="Id" CardinalityMin ="0" />
+     <Component name="Address" CardinalityMin ="0" CardinalityMax ="1"
+       cue:DisplayInline="true ">
+         <Element name="Street" />
+         <Element name="Place" />
+         <Element name="Country" />
+     </Component> 
+</Component> 
 }}}