| 26 | | Description |
| | 26 | * A separate namespace for application cues, e.g. http://www.clarin.eu/cmdi/cues/1.0 |
| | 27 | * In this namespace attributes are defined (in a separate XSD) for all kinds of display cues etc, e.g. background colours or instructions to merge all subcomponents |
| | 28 | * The general component specification allows any attributes from this namespace on all components, elements and attributes |
| | 29 | * 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) |
| | 30 | * The component-to-schema XSLT picks up all cues and wraps them in app info blocks in the profile XSD |
| | 31 | * When requesting a profile from the Component Registry, it can be instructed to apply a style (or maybe multiple), e.g. by getting http://catalog.clarin.eu/ds/ComponentRegistry/rest/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 |
| | 32 | |
| | 33 | Some meta-notes: |
| | 34 | - The style should probably inject the namespace definition and schema location into the component spec so that we can have independent versioning of styles |
| | 35 | - Applications can choose which cues to support and which not, and will also likely support a specific version of the style 'language' |
| | 36 | - Maybe we want to have several 'sub-namespaces' for different kinds of cues (e.g. editor cues, viewer cues, ...) |
| | 37 | - We need a set of example cues to illustrate this |
| | 38 | - 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) |
| | 39 | - Another registry... will this go down well? :) It could be integrated with the Component Registry though. |
