Moving this to the XBib list, since, as I said on one of the forum
threads (http://forums.zotero.org/discussion/2004/), this mostly just
requires an up-to-date CSL processor that can be run on a server.
Some options, depending mainly on your language of choice:
-
Pick up one of the existing processors. The XBib repository
(http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/) has processors in
Ruby, Python and XSLT, but they’re quite out-of-date. Various people on
the XBib list can tell you more about the processors’ respective statuses.
-
A few days ago, Ron on the XBib list mentioned starting a PHP
version, which may be the most promising for the near future, if for no
other reason than that it’s pretty easy to port JavaScript to PHP, and
Zotero’s JS-based processor is the most up-to-date version. You can talk
to him and see if he wants help.
-
Help separate Zotero’s JS processor from any Mozilla/Zotero
dependencies so that it can run in Rhino or, when it develops Linux
support, Jaxer. We’d want to do this in such a way that changes in
Zotero could be transferred to the standalone version (“citeproc-js”) as
easily as possible.
-
Write some JS code to automate the process using Zotero itself,
either in response to Firefox command-line arguments (probably POSTing
the results back to a particular URL) or with a tiny embedded webserver
responding to requests (the same way the Word/OOo plugins talk to
Zotero). All the code to generate previews is already in cslpreview.xul,
so you’d just need to write code to pull a style from a passed URL and
return the output. The sample data would just exist in the Zotero
library on the host machine.
While not the cleanest solution, #4 is probably a few hours’ work and
would ensure that the previews were always up-to-date with the latest
changes in Zotero.
Hello,Op 5 feb 2008, om 09:21 heeft Dan Stillman het volgende geschreven:
- Pick up one of the existing processors. The XBib repository
(XBib download | SourceForge.net) has processors in
Ruby, Python and XSLT, but they’re quite out-of-date. Various people
on
the XBib list can tell you more about the processors’ respective
statuses.
The Python processor (citeproc-py) is not functional. I moved it
towards a more object oriented approach over the weekend, but it not
usable now at all (over ever really was before).
Johan Kool
Peacock
- Proudly presenting the peaks… -
http://peacock.johankool.nl/
Dan Stillman wrote:
…
- Help separate Zotero’s JS processor from any Mozilla/Zotero
dependencies so that it can run in Rhino or, when it develops Linux
support, Jaxer. We’d want to do this in such a way that changes in
Zotero could be transferred to the standalone version (“citeproc-js”) as
easily as possible.
I do think this should be an important goal irrespective of the
particular request here. Along with that, I’d remove the dependence on E4X.
But I wouldn’t call this critical now, unless someone simply has the
time, skill and interest.
- Write some JS code to automate the process using Zotero itself,
either in response to Firefox command-line arguments (probably POSTing
the results back to a particular URL) or with a tiny embedded webserver
responding to requests (the same way the Word/OOo plugins talk to
Zotero). All the code to generate previews is already in cslpreview.xul,
so you’d just need to write code to pull a style from a passed URL and
return the output. The sample data would just exist in the Zotero
library on the host machine.
There’s a simpler solution, isn’t there?
- write a script that generates one or more static previews. Use JS to
load/display them as needed.
There’s another area for improvement in the repo interface: making use
of the style metadata. For example, imagine a having them grouped by
class (author-date, note, etc.). You could even use some magic like here
to make it all beautiful and functional:
http://blogmarks.net/user/depositado/marks/tag/menu
Bruce
- A few days ago, Ron on the XBib list mentioned starting a PHP
version, which may be the most promising for the near future, if for
no
other reason than that it’s pretty easy to port JavaScript to PHP, and
Zotero’s JS-based processor is the most up-to-date version. You can
talk to him and see if he wants help.
I guess Dan was fishing for a progress report, so here it is… 
I have made some progress citeproc-php, but it has a way to go before
it’s usable code. Maybe in a week or two (time permitting) there might
be a prototype available.
Ron.
Nice Johan!
BTW, you included the compiled python files in the repo; did you mean
to do that?
Bruce
Dan Stillman wrote:
- Write some JS code to automate the process using Zotero itself,
either in response to Firefox command-line arguments (probably POSTing
the results back to a particular URL) or with a tiny embedded webserver
responding to requests (the same way the Word/OOo plugins talk to
Zotero). All the code to generate previews is already in cslpreview.xul,
so you’d just need to write code to pull a style from a passed URL and
return the output. The sample data would just exist in the Zotero
library on the host machine.
There’s a simpler solution, isn’t there?
- write a script that generates one or more static previews. Use JS to
load/display them as needed.
A script that runs where? Manually, in Firefox, on a desktop machine? We
can do that, of course, but the whole point of the styles page is that
it’s updated automatically as commits come in… Or did you mean
something else?
There’s another area for improvement in the repo interface: making use
of the style metadata. For example, imagine a having them grouped by
class (author-date, note, etc.).
It’s certainly on the list, along with creating the Atom-based feed to
support updating of non-default styles.
There’s a simpler solution, isn’t there?
- write a script that generates one or more static previews. Use JS to
load/display them as needed.
A script that runs where? Manually, in Firefox, on a desktop machine? We
can do that, of course, but the whole point of the styles page is that
it’s updated automatically as commits come in… Or did you mean
something else?
I don’t know; I guess it’d have to be running on the server machine so
that when the repo is updated, the previews get regenerated.
Am just saying that there doesn’t really need to be any user
interaction involved on the client end.
There’s another area for improvement in the repo interface: making use
of the style metadata. For example, imagine a having them grouped by
class (author-date, note, etc.).
It’s certainly on the list, along with creating the Atom-based feed to
support updating of non-default styles.
Yeah, I wasn’t pressing you guys; just noting it in case anyone else
has time or interest in working on this.
Bruce
Right, that’s #4. Zotero needs to be able to respond to requests in
order to automate this. I wasn’t suggesting it had anything to do with
end users (though allowing access to the Zotero CSL processor via an
embedded webserver could be useful for other reasons).