Hi all,
indeed I wasn’t aware of Fred’s work. If what I’m proposing already exists -
all the better. I must admit that I’m not able to fully appreciate the
discussion, because (as Carles points out) I have literally zero programming
knowledge, much less of the inner workings of CSL. Hence, I wasn’t even able
to try Fred’s prototype - I’ll have Carles show it to me in the office next
week.
So my entire contribution is just from a UI and user perspective. Ideally, I
believe UI mockups and user experience should be agreed upon first, and then
it should be decided how to best achieve this technically (and from reading
the thread, it’s apparent to me that Fred also had specific ideas about the
UI/UX in mind before he started coding).
Regarding Sean’s question as to how my proposal differs from Fred’s, I can’t
really tell without having tried the prototype. Generally though, I think
it’s important to have a browser-independent web app, and it should work
whether or not you have Mendeley or Zotero installed.
My hope in writing up the spec was to solicit feedback in order to come to
an agreement about the UI. Once we have reached this agreement, Mendeley
would like to commit developer time to build the web app - ideally getting
started within the next few weeks, and having a working version up on
www.citationstyles.org within the next 2-3 months. If Fred’s code can be
reused to speed up development, wonderful!
Here are some thoughts to follow on from Bruce’s views about reduced
reliance on defining per-type formats at the top level.
I think that the possibility of per-type formatting needs to be in
there. Some styles do need this, and it doesn’t always make sense to
push the conditional into a macro. But there are big gains from
emphasizing macros in the design, I think.
There is a great deal of complexity lurking in the five main rendering
nodes of CSL (names, date, number, text). I may be overly impressed
with what we have added and refined for CSL 1.0 over the past few
months, but I wonder whether it is really feasible to get a usable
tool together that covers all of the possibilities and produces valid
CSL files in 2-3 months’ time. But with an approach that starts off
macro-centric, most of the detail can be dropped on the floor for the
time being, without losing the benefits of a WYSIWYG interface.
The repository contains quite a few styles already, most of which are
built out of macros. There is also a small but active population of
style authors skilled in crafting macros by hand. One option would be
to initially forego any attempt at all to support sub-element
formatting of the five main rendering elements in the gui, but instead
rely entirely on macros to supply them, and assume that new
hand-crafted macros will be added to the library on demand as the need
arises.
This would largely eliminate the need to express conditional branching
in the gui, which is a difficult problem not addressed by proposals so
far (I think – I haven’t yet run Fred’s tool). Two forms of
branching cannot be completely pushed into macros: that for residual
item-type formatting; and that needed for first-ibid-subsequent
formatting. It would also leave – and throw the focus on – another
condition-related issue that (I think?) has also not yet been
addressed: the use of grouping (with an intra-group delimiter and a
group-wise prefix and suffix). Grouping is an essential feature of
styling logic, and although it’s not immediately obvious how best to
express it in a gui, it’s probably an issue worth focusing on pretty
closely.
If you went this route, the first step (before deployment of CSL 1.0?)
would be to set up for automated repository housecleaning, identifying
macros that have exactly the same CSL definition, giving them uniform
names, and extracting them to a WYSIWYG library archive that can be
updated automatically from the raw contents of the repository. Some
means of automatically assigning descriptive names to macros would
need to accompany that, to provide consistent and meaningful names
without human intervention.
Once you had the workflow set up, basically everyone would continue
working as they do currently, but with the WYSIWYG environment
benefiting incidentally from tweaks and extensions introduced to style
macros the archive, either by style authors working in the Old Way, or
by macros supplied on request to WYSIWYG-reliant authors.
As Bruce suggests, element-level formatting options on the five main
elements could be introduced into the gui according to need. But in
the first cut, you might treat it as a distraction, and leave it out
completely, in order to focus on the attributes of group, layout,
sort+key and a few items on the top-level style node.
Frank Bennett