Changes between Version 3 and Version 4 of CMDI 1.2/Cues/Display information/Summary


Ignore:
Timestamp:
03/11/14 15:36:12 (10 years ago)
Author:
Twan Goosen
Comment:

slimmed down and some minor changes

Legend:

Unmodified
Added
Removed
Modified

  • CMDI 1.2/Cues/Display information/Summary

    v3 v4  
    77== Issue description ==
    88
    9 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 exception of the ''displayPriority'' attribute). 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 like (conceptually) CSS and XML.
     9CMDI 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.
    1010
    11 Display aspects that might be included:
    12 
    13 * Grouping information
    14  * Grouping of elements within components
    15  * Merging of components on one level
    16  * Merging of components contained within one other
    17 * 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).
    18 * Field display mode reflecting importance
     11Display aspects might include grouping and merging information, salient element selection (as an alternative to 'displayPriorty') and an indication of importance beyond cardinality.
    1912
    2013== Description of proposed solution ==
    2114
    22 A '''separate namespace''' is used for display cues (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.
     15A '''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.
    2316The 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.
    2417
    25 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'''.
     18The 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.
    2619
    2720[[Image(extended display info.png)]]
    2821
    29 Notes:
    30 * The style injects the namespace definition and schema location into the component spec which allows independent versioning of styles
    31 * Applications can choose which cues to support and which not, and will also likely support a specific version of the style 'language'
    32 
    3322The required '''infrastructure''' extensions will be developed at a later stage and are not part of the CMDI 1.2 specification.
    3423
    35 
     24Note that different versions of the style 'language' can potentially exist and tools can support one or more (subsets) of these variations.
    3625=== General Component Schema changes ===
    3726
    … …  
    4332=== Profile schema changes ===
    4433
    45 The display cue attributes are inherited on the element and attributes definitions in the schema file.
     34The display cue attributes are transformed into [http://www.w3.org/TR/xmlschema-1/#cAnnotations xs:appinfo] elements below element and attributes definitions in the schema file.
    4635
    4736=== Instance changes ===
    … …  
    5241There 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:
    5342
    54 
    5543* Extension of the Component Registry with some kind of 'style registry' and "style editor'
    5644* Extension of the Component Registry API with additional parameter ('style') to activate the augmentation of the component specification with style information
    5745* Metadata editors and all CMDI viewers (like the VLO) may use this information for enhanced display (and may decide to use only a subset)
    58