Leigh
- Character state notes
DELTA stores all notes as plain text, sometimes marked up with its own typesetting marks, but pretty plain nonetheless. LucID allows builders of keys to associate a formatted file (txt, rtf, html) with a character state, to hold explanatory notes. One option would be to include xml markup as comment (would this be messy if the notes included embedded images, hotlinks etc). Another would be to treat state notes as you do images, with an href pointer to a file. LucID also allows sound files to be associated with a state (imagine a key to cicadas or frogs with calls as characters).
How about if the text allowed (X)HTML markup to me used. This would allow the full range of HTML expression (tables, bold, images, etc). However it would mean tht processors (e.g. a stylesheet) would need to understand HTML. I suggest that a subset of the available markup would be enough in most cases. A pointer to additional document(s) would also be useful.
Yes, I think we'd need to allow for both - embedded (X)HTML and pointers to external documents, from which an application could fetch stuff if necessary. I have a key with 800 states each with html notes, images etc. Embedding all this would make for one hell of a document.
- Taxon multimedia
LucID allows any number of multimedia files (images, videos, sounds, txt, rtf, html).
Ideally an XML format would allow this as well. A generic 'link' to additional information could be used. It then depends on the application to decide whether it can fetch, and handle the particular multimedia format.
Ditto as for state notes
- Taxon subkeys
In LucID keys one key may be linked as a child to another. A taxon thus has the name of a subkey associated with it, so that a user on reaching the taxon can ask the program to automatically drop to the subkey
to
continue the identification.
If I understand this correctly you mean that the subkey provides additional information regarding the taxon. To take a trivial example, the first key may identify a plant to the Family level, whilst the subkey had additional information - e.g. to the species?
If so, then this is related to the document linking problem below...
Yes it's a linking issue. By allowing links from one document to another you can build hierarchies of documents e.g. I have a key to Families of Flowering Plants of Australia: the family Solanaceae has a link to a separate key to genera and species of that family, and some of these taxa have further subkey links. The hierarchy of keys-subkeys is being built up in an ad hoc fashion.
- General Information
Not all information in a key or other treatment can be associated with character states or taxa. Some is associated with the treatment as a whole e.g. introductory notes, notes on using the key, general notes for the parent taxon of the key (e.g. a key to genera of Grossulariaceae may have a description of the family) etc. In LucID this information may comprise html files, images etc just as with taxa and states. This could
be
easily dealt with by expanding your DTD. A special case is an "About this
key"
file. This needs much more than is allowed in the document description:
This is one area that I don't think we've touched upon to a great extent (I could be wrong). Heres a question:
- is it enough to just have an 'additional information' element
so that any required explanatory notes, etc can be added there.
Heres my answer (and I'd welcome comment):
No its not. It would be useful to try to quantify this additional information, so that a generic catch-all placeholder isn't used. This sidesteps issues such as that shown by the comment marker in DELTA which ends up being used for all sorts of other uses. Its this kind of information which is highly useful both to the user, and the application developer: the user has a defined place to add his/her information, the developer has explicit cues on how particular sections of information should be used.
So to start a running list: - introduction - about this key? - parent taxon / related keys - usage guidelines - other meta information? (see above - copyright, funding body, author, change
history, etc).
Anything else?
I wouldn't like to try to force people into boxes here. It may be that there are some "General Info" topics that are fairly common, but you can't predict how someone will want to structure this. For instance, someone writing a key to insects might want to have a topic covering collecting techniques, another would want general info on biological control. A user here who has published a key to eucalypts of Australia has included a synoptic classification.
Best option again I think would be to be very general and allow flexible links to external files with topic names.
You've commented that you're just getting to grips with DTDs, is it going to cause a great problem if I design the next version of XDELTA using XML Schemas [1,2]? Schemas provide a great deal more flexibility when defining document structures, as well as validation (not that I expect the latter issue to matter to a huge degree in this context). The are some structures in the XDELTA DTD which I'm not particularly happy with, but are imposed by the limitations of DTD syntax. I'm hoping that Schemas will remove some of these constraints.
When I get chance to attempt another iteration of XDELTA (hopefully quite shortly), I can fully document the Schema to bring people up to speed - i.e. use XDELTA as a tutorial piece.
Great, and you're a bloody marvel!
I also don't want to appear to be leading everyone by the nose towards an XML based format, or one which I've produced myself. So please consider XDELTA, as I've always maintained, as a discussion point.
I agree it's still a discussion point but it's the best we have so far to start bringing this discussion towards a product, doing which will bring out extra points, flaws, limitations etc. If you're willing to do the work on it, then I'm sure we're willing to comment and pick the holes.
Cheers - k