Another mockup: http://imageshack.us/m/69/5963/repository.png
Rintze
Hi,
Carles,
…
I would not do it, I expect the cs:updated to have the timestamp in
the repository, so it’s easy to clone, users can just browse the
repository using the github interface and download the ready-to-use
style, etc.Except that the github interface lists updated date-times for all
files by default already.And how do you respond to my previously noted problems? To repeat …
There are a variety of issues with forcing style authors to update the
cs:updated values manually:
- it’s tedious
- it’s error prone (easy to forget to do, most basically)
- it mixes content and metadata (the metadata changes the sha1 value)
I would update the cs:updated when pushing with the pushing date, no?
You mean like pre-commit or pre-push script?
yes, automatically. I should check which hook exactly (I don’t see a pre-push).
That solves some of my issues above, but not all of them.
It only leaves the last issue, right? Can you elaborate a bit more? (I
don’t see the problem of changing the sha1 in the pre-commit hook, if
you mean that this is the problem). Maybe a git specific problem?
(I’ve never changed files during the pre-commit).
For me, the cs:updated is the same (mainly) than a version: a
number/string that it’s incrementing and easy to compare, so given two
style id’s I could know the most recent.
As far as I know the common practise with other software repository is
to have the version in some file in the repository, so this is
commonly used this way. But in our case each commit is a different
version, so we should automate it.
Just my thoughts,
I said above: we just haven’t bothered, because this way is easier, and
we’ve always run it from post-commit (which made it basically identical
to the commit time). If there end up being other sources, we can switch
to using the git value.
Hi,
By popular demand[1], I’ve updated the Zotero styles page to use CSL 1.0
I’m very happy to read and see it!styles from GitHub, and I’ve taken the opportunity to add some new
the “old” page had, at the end, a “Get Involved” section. Do you plan
to add the same? (I guess that redirecting the people to the github,
etc.?)
This page has links at the top to both citationstyles.org and the CSL
development wiki page on zotero.org (which in turn links to GitHub). The
wiki page can definitely be improved, but linking directly to GitHub
doesn’t provide a whole lot of context (and for most users who want to
edit or contribute styles, its instructions�fork the repo, etc.�aren’t
very helpful).
search features, with the ability to filter by name, dependent status,
citation format, and field.
yes, looks neat. Hopefully the previews will be there soon.
Hoping to get those up in the next few days (and launch the page at that
time).
The install links are disabled for me, using the Zotero ML builds.
What can you or I do to make the page recognize these builds as a
version of Zotero 2.1 and enable the install links?
I’m sending X-Zotero-Version: 2.1m9222
Avram
Well, it’s what I said earlier: that the only way to do it (as far as I
know, and it’s the only way that really makes sense) is client side, and
from what I gather of the page Bruce linked to [1], everybody who
committed would need the script (and underlying interpreter) in question
to be available on their system, since the only thing synced is the
.gitattributes file.
I feel like christmas came early! Thanks so much, this looks great!------
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University
2.1m9222 is technically a lower version than 2.1, and we were testing
for >=2.1, but try now.
Works now. Thanks!
Carles,
…
I would not do it, I expect the cs:updated to have the timestamp in
the repository, so it’s easy to clone, users can just browse the
repository using the github interface and download the ready-to-use
style, etc.
Except that the github interface lists updated date-times for all
files by default already.And how do you respond to my previously noted problems? To repeat …
There are a variety of issues with forcing style authors to update the
cs:updated values manually:
- it’s tedious
- it’s error prone (easy to forget to do, most basically)
- it mixes content and metadata (the metadata changes the sha1 value)
I would update the cs:updated when pushing with the pushing date, no?
You mean like pre-commit or pre-push script?
yes, automatically. I should check which hook exactly (I don’t see a pre-push).That solves some of my issues above, but not all of them.
It only leaves the last issue, right? Can you elaborate a bit more? (I
don’t see the problem of changing the sha1 in the pre-commit hook, if
you mean that this is the problem). Maybe a git specific problem?
(I’ve never changed files during the pre-commit).Well, it’s what I said earlier: that the only way to do it (as far as I
know, and it’s the only way that really makes sense) is client side, and
from what I gather of the page Bruce linked to [1], everybody who
committed would need the script (and underlying interpreter) in question
to be available on their system, since the only thing synced is the
.gitattributes file.
That’s right. Just to clarify:
- I presume we could include the script in the repo if we wanted
- if the script or interpreter isn’t available locally, the checkout
will still work; it’s just the cs:updated value won’t get set
Carles also asked:
I thought something similar for www.citationstyles.org, maybe can be
partially reused? I forgot if someone was working on it (I remember
Bruce talking about some software to prepare tables).
Perhaps we ought to talk about where we’d like this to do?
Ideally, I want an index and WYSWIYG editor hanging of
citationstyles.org, but am not sure how best to get there.
Bruce
I think it’s specific to distributed version control in general.
In git, there are hooks for all manner of stuff (pre-commit,
post-receive, etc.), but none of them seem to involve modifying
source; they typically just fire off a process (say an email, run a
validation, etc.).
Bruce
- Style previews are forthcoming—just waiting on some improvements to
citeproc-node. Do we have any sample data that covers more than the data
used on the old styles page?
As Bruce already indicated, not yet.
- We’ll be replacing the old styles page with this one within a few
days. At that point, after Rintze does a final merge, we’ll remove the
‘csl’ directory from Zotero SVN and archive the old styles page at
/styles-old so that users of older clients can still find CSL 0.8 styles
if need be.
I did a merge yesterday (some styles have started to diverge in the two
repos, but I think I covered most of the style updates), so the github repo
should be up to date.
Rintze
Previews are now up.
http://www.zotero.org/styles-new
For now I just went with the sample data we were using on the old repo.
Better data would definitely be good.
We’re getting an error with some of the previews that we need to look
into, but most of them appear to be working. Faolan is working on
getting Frank’s test suite hooked up to citeproc-node so that we can
ensure that the output is accurate�we’ve had to fix some rendering bugs
already, and there may be others.
Previews are now up.
One nitpick: the preview box always goes down, which means that I cannot see
the preview for styles near the bottom of my browser window (and scrolling
isn’t a solution for the last few styles on the page).
For now I just went with the sample data we were using on the old repo.
Better data would definitely be good.
Better how? Is the range of item types too limited? If so, would it be
feasible to use different sets of data for styles in the different fields?
E.g. for the sciences, the main item types are probably journal articles,
books, book chapters, patents, thesises and reports, while fields like law
and humanities are likely to be more diverse.
Rintze
The current preview stuff isn’t too bad, but could probably be
enhanced along lines I suggest in that ticket.
BTW, the doi URL and access dates for many of these (e.g. the journal
article) sample data should be removed.
Bruce
BTW, where the hell is the sample data? If it was available, say, in a
github repo, I would have already fixed some of the problems I note
(including wrong dates) and issued a pull request.
Where, ideally, do we want this sample data?
Alright, I added a placeholder that we can work on as time permits
(not entirely valid; still resisting using the data representation!).
https://github.com/citation-style-language/utilities/blob/master/preview.json
As a reminder, you can now edit (including forking and issuing a pull
request) directly in the github interface. So feel to add to this,
according to the suggestions outlined on this ticket:
https://github.com/citation-style-language/styles/issues/4
Bruce
Just curious: how difficult would it be to add support for JSON import and
export to the Zotero client (using the citeproc-js data model)?
Rintze
Someone could pretty easily write a translator for it, using
Zotero.Cite.System.retrieveItem() in cite.js as a guide for exporting. I
don’t think there’s really much reason to add that to the client by
default, though, since it’d be useful mainly for the people on this
list, and it’s not intended to be an interchange format.
I think that’s still TBD.
Pandoc supports CSL JSON as an end-user input format, so there’s at
least one example.
There’s been periodically efforts at a bib json representation over
the past few years, including a fairly high-profile one around HTML5
microformats. While never designed with this intention in mind, I
think CSL JSON (particularly once we stabilize it) is as good a
candidate as any for this sort of lightweight, but flexible, bib
format.
FWIW, I used json here just because it’s the primary input format for
citeproc-js, so was assuming it’s appropriate.
Bruce