| 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 |
| | 26 | A '''separate namespace''' is used for application cues (e.g. http://www.clarin.eu/cmdi/cues/1.0). In this namespace attributes are defined (in an independent XSD) for all kinds of display and interaction cues. |
| 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. |
| | 28 | The 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 (for an example, see below). |
| | 29 | |
| | 30 | 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 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'''. |
| | 31 | |
| | 32 | Notes: |
| | 33 | * The style should probably inject the namespace definition and schema location into the component spec so that we can have independent versioning of styles |
| | 34 | * Applications can choose which cues to support and which not, and will also likely support a specific version of the style 'language' |
| | 35 | * Maybe we want to have several 'sub-namespaces' for different kinds of cues (e.g. editor cues, viewer cues, ...) |
| | 36 | * 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) |
| | 37 | * The 'style registry' could be integrated with the Component Registry though. |
