-> Home Page
-> QTI Links
-> Mailing List
Sorry. The XQuestion converter is no longer available. It has been replaced with the desktop application Question Writer
Styles in XQuestion
XQuestion extends the QTI 1.2 specification to allow every single element to have a 'class' attribute. (In the QTI specification, only the flow elements have a class attribute). XQuestion also allows styles to cascade down through the structure - if you define an assessment as having red text for text elements, then every piece of text will be red. You could redefine a particular item in that assessment to have blue text for text elements - then every piece of text in that item would be blue, but the rest of the assessment would use red text.
Let's see how that works...(many elements and attributes omitted for brevity)
In the example above, items 1 and 3 will be rendered as red text, and item 2 as blue text. Item 2 overrides the assessment setting.
The Style Document
The style document is usually called styles.xml and has this kind of structure..
The label 'redtext' really is just that, it references the style to use. You could quite happily reverse the labels so that the assessment labelled 'redtext' would display in blue and vice versa (you wouldn't be happy if you did this, you'd be sick). The meaning that 'redtext' has is defined by the styles document.
Labels Can Reference Many Styles
Let's say we want all the red text to be left aligned and to have a point size of 16, we'd do this...
In fact, usually you want to define every possible style as the label, 'default' and then apply this to assessment. This gives your assessment all the default styles that it needs and then you can over-ride the defaults as and when you need to. That structure is used in all the example files. It looks like
Elements Can Have Many Labels
As if it weren't complicated enough, elements can have many labels. You can happily ignore this bit if your head is beginning to hurt - you won't need it for ages.
Let's say we've got an item and we'd like all the mattext to appear black, 18 point size, and we've got another item where we'd like the text to appear black, 18 point size and in italics, we can define a style for the 'black and 18 point size' and another for the 'italics'. That might look like this...
The Exception to the Rule
You definitely don't need to know this. Don't even read it.
You'll remember earlier that I mentioned that flow elments already have a 'class' attribute. They also have a default of 'Block' defined. That's Block with a capital 'B' - style labels are case-sensitive. Usually you should use all lower-case for styles, but this is already defined. So what effect does this have? It means that if you don't define a class for a flow element, it will have one anyway, and anything it defines will not cascade through safely. This is usually a good thing - putting something in a flow is meant to force it to be rendered in some particular way.
Here's an example
The flow contains three flow elements - each has some material in it. The flow action for the outside flow is 'horizontal' so it will lay these three out side by side. Now, you'd expect the flows inside to inherit the flowaction but they don't. They use their own default, 'Block' and the materials are laid out block style, one after the other.
If you're having difficultly grasping this concept, then just imagine that a pre-processor does this to the test.xml...
convert <flow> to <flow class="Block">
thus giving us
And that's it. That's all there is to know about how style works.