Data format agnosticism is always a good thing.Cainntear wrote:What I mean is about making it "semantic" in the sense that the file tells us the information, not the formatting.[...]
If you look at the likes of text2qti, the AMC-text
[...]
In theory the same format could be used to import directly into anything (including the likes of your and my apps)[...]
If I choose to render this as a numbered list [...]. Or maybe I stick them in a table so that I get columns to print out.
I try to think of my data in these format-agnostic ways.
However, while I am all for going 'semantic' over 'formatting' -based, formatting is arbitrarily based on having something that is in the file, i.e. "line break" or other characters in a data stream, interpreted as control codes and used to actually break lines and such -- so in the end there is no big difference...
From a slightly more abstract point of view, what the generator will be doing (for exercises, but also in general) is little more than string search and replace: this ("dynamic element" or whatever) is found in input i.e. the text as typed by the exercise writer, or imported from a file, etc., and it is replaced in output with that (<HTML code>).
All that thus matters is what delimiters we choose for each exercise dynamic element, and / or any sub-parts. I think regular expressions allow for enough flexibility both in input and output, and a template system would give us even more, if used to read or store our delimiters of choice.
Just like any number of spaces and line breaks in HTML source are condensed to a single space for rendering.In text2qti and most similar things, a single line break doesn't have any independent meaning -- instead it's having specific characters at the start of the line that counts. This means you can break a line if you need to stop it getting too long -- see question 11 above (text2qti treats any line starting with space or tab as being a continuation of the previous line, and it replaces the newline and all initial space with a single space in the output).
OK, the problem with considering single line breaks in 'simple' input is that they are too likely to end up in the input by accident -- either because people tend to insert them before long lines wrap automatically in text areas, or because it should be possible to import plain text files which may include them. But delimiters consisting of specific x/y/z strings at the beginning of a line are really nothing more than "line break + x/y/z" strings, so for these to be useful we should make sure we're using stuff that is less likely to be accidental. Like perhaps, double line breaks ; )