Changes between Version 18 and Version 19 of CMDI 1.2/Cues/Display information

Timestamp:

02/11/14 14:59:09 (10 years ago)

Author:

twagoo

Comment:

--

CMDI 1.2/Cues/Display information

@@ -140 +140 @@
 * 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?
 
+----
 
+'''Twan''': An illustration of the need for display cues (taken from the WG e-mail discussion):
 
+The grouping issue is the most predominant one, so good thing you're mentioning that. The essence of the issues lies in the fact that there are two factors determining the component hierarchy in a profile: purposeful nesting - to reflect some natural hierarchy or, more typically, to allow repetition of a set of elements or components - and nesting as a result of component reuse. Take for example the cmdi-actor component:
+
+''Actor''
+* Role
+* Name
+* ...
+* ''BirthCountry (0:1)''
+ * ''iso-country (1:1)''
+  * Code
+* ''cmdi-actorlanguages (0:1)''
+ * description
+ * ''cmdi-actorlanguage (1:*)''
+  * ...
+  * ''cmdi-language (1:1)''
+   * LanguageName
+   * ''iso-language-639-3 (1:1)''
+
+I think this component shows some reasonably good examples of component reuse. However the resulting hierarchy is a nightmare if you were to represent an instance of it it in a tree based view with tables per component (like in Arbil). What you would like to have is something like
+
+''Actor''
+* Role
+* Name
+* BirthCountry.iso-country.Code
+* ''cmdi-actorlanguages''
+ * description
+ * ''cmdi-actorlanguage.cmdi-language'' (repeated)
+  * LanguageName
+  * iso-language-639-3.iso-639-3-code
+
+Where the tree is condensed, basically leaving out the levels that are an artifact of component reuse. Arbil is currently trying to achieve that by flattening all 0:1 and 1:1 branches in the tree. But then we got complaints about Arbil not representing the hierarchy of the components as modelled! So I think (unfortunately) there is no generic solution to this problem apart from providing a way of augmenting individual components with instructions like 'join children from here' for the editor or viewer. As far as I can tell this can only work top-down, but that should be powerful enough. 
+
+----
 
 Discuss the topic in general below this point