I know it is an obvious statement but what is available is aimed at developers. E.g. our librarian is a layout expert, has a basic knowledge of xml and would find it very easy to incert a new record into a database; at the same time she is very busy.
For the existing tutorial to become a guide it would need to become a simpler overview to modifying a template.

I feel the following is missing -

- examples. The tutorial could pick a layout and show what a reference would look like in Word. It could then show changes required to an existing record. As formatting tend to be different for each type of reference, examples could be given for a reference to a journal, a book and/or an URL.
To cater for people who is uncertain about xlst, you could point to other websites e.g. http://w3schools.com/xsl/xsl_choose.asp.

- A list of possible variables/parameters would also be sensible. E.g. in the tutorial we are refering to, it gives an example for a book - what is the id for a journal article or a magazine article?

There are other possibilities - a small example on how to transform using a third party product; if there are a number of layouts around which couldn't make it into the released software, they could be listed or referenced on some page; the same goes for any tools.

- examples. The tutorial could pick a layout and show what a reference would look like in Word.

Good point, though I won't be showing what it looks like "in Word." CSL is completely agnostic about how it's used, and I actually started on all of this to free myself from Word (and Endnote).

But, the plan is to have two documents for CSL: a proper (and more formal) specification, and a tutorial. The two together will cover what you're looking for.

However, the focus will remain primarily developers, because I want to see GUIs built such that users don't have to deal with the XML directly. But there ought to be a way to make it possible for ambitious users to work it out.

Michael, yes, Zotero needs to deal with abbreviation. But it's a non-trivial problem to do it right. For example, your "preferred form" is in fact style-specific. Other styles no doubt would prefer the punctuation left off. Also, it seems to me the solution ought to also encompass other kinds of abbreviation, such as organization names.

It would be nice to see the Zotero 2.0 functionality include functionality that can ease this. Periodicals really need to be treated as a first class citizen there, complete with canonical abbreviations.

Series Titles also need to be able to be abbreviated. (Would it be possible to add place for it in the database/UI even now?)

And it's probably worth adding to this discussion that the use of abbreviations for some fields will depend on the preference of the author (/editor/publisher) with respect to the particular writing project. A literary critic who abbreviates a title for one project where it is central will want to use normal citation for the same title in a case where it is cited less frequently. This might be usefully incorporated into the UI. (Something like custom abbreviation lists which override canonical abbreviations, and could include abbreviations for any of the above fields: Journal Title, Series Title, Archival Collections, Main Item Title, organization, publisher).

Whatever approach is taken, as long as the appropriate styles/layouts are not available, potential users cannot switch from packages like Endnote.

Is it really necessary to keep repeating this? Most of us involved in this work are publishing scholars and former Endnote users. We understand the problems perfectly well. Be patient please.