Comments

I just want to make a comment here that may prove useful to some. It's relevant because the same issue shows as a weakness in the current SourceTemplates data model.

The element descriptions shown here are part of the User Interface and hence not part of the primary definition of the corresponding source-type. This may sound a little pernickety but it's extremely important during localisation.

Going back to our source+citation threads, the 'Definition' (i.e. the number of elements, their tag names, and their data-types) are held as a function of some Key representing the source-type. As discussed elsewhere, I strongly favour a URI but we'll stay generic here.

The element descriptions, as shown in this image, must be held in a different place and would be a function of the same Key plus the user's Locale. It would include all things relevant to soliciting data from that user's computer interface. As well as the element descriptions, it would include descriptions of the source-types themselves that would be used in any drop-down list.

Finally, there should be a third set of data that relates to what a few of have called the report-writer module. This is basically the software module that generates readable content in a full report, a chart, or on the screen. This where a normal written citation reference (incl reference note and/or blibliography) would be generated from the stored electronic version. As a result, it must be a function of the same Key plus the user's Locale plus a citation style. The style could be a "standard" one like CMOS or a custom private one that would be guaranteed to be portable for all your source-types.

Tony