Is this worth adding? It’s required for my EndNote to CSL style
converter to work properly, since EndNote doesn’t use localized terms,
but otherwise I don’t know what utility it would have. If the answer
is no, the converter can just produce slightly invalid CSL.
Simon
Simon Kornblith wrote:
Is this worth adding? It’s required for my EndNote to CSL style
converter to work properly, since EndNote doesn’t use localized terms,
but otherwise I don’t know what utility it would have. If the answer
is no, the converter can just produce slightly invalid CSL.
“Slightly invalid”? From the schema perspective, it’s either valid, or
it’s not.
Can you clarify, and also give us an example of how such an addition
would impact the markup in this case?
Bruce
Simon Kornblith wrote:
Is this worth adding? It’s required for my EndNote to CSL style
converter to work properly, since EndNote doesn’t use localized
terms,
but otherwise I don’t know what utility it would have. If the answer
is no, the converter can just produce slightly invalid CSL.“Slightly invalid”? From the schema perspective, it’s either valid, or
it’s not.
Only if you don’t check what the errors are. There’s a huge difference
between knowingly breaking with the schema by using a single
unsupported attribute on some element (which, e.g., RDFa encourages
you to do) and generating something completely invalid.
Can you clarify, and also give us an example of how such an addition
would impact the markup in this case?
I don’t know of a good use case for handwritten styles. With the
converted EndNote styles, we end up with:
Not something you’d want in a new, handwritten style, but in this
case, there’s no way around it. Zotero is going to implement this
attribute whether it’s in the schema or not, but these converted
styles will probably only exist in the Zotero DB, not as files. Simply
having the attribute in the schema wouldn’t really encourage this kind
of usage, since it’s much more awkward than the alternative, but I
don’t know what application it would have for styles that conform to
best practices.
Simon
Simon Kornblith wrote:
Only if you don’t check what the errors are. There’s a huge difference
between knowingly breaking with the schema by using a single
unsupported attribute on some element (which, e.g., RDFa encourages
you to do) and generating something completely invalid.
And how would you define the difference?
If there’s need to allow foreign attributes, then the schema can and
should allow it. Otherwise, it seems pretty clear to me the schema
author considers such additions to be invalid.
Ergo, if there’s a need to allow foreign attributes in CSL, then we
should define that in the schema. If we decide that’s not a good idea,
then don’t do it.
Can you clarify, and also give us an example of how such an addition
would impact the markup in this case?I don’t know of a good use case for handwritten styles. With the
converted EndNote styles, we end up with:Not something you’d want in a new, handwritten style, but in this
case, there’s no way around it. Zotero is going to implement this
attribute whether it’s in the schema or not, but these converted
styles will probably only exist in the Zotero DB, not as files.
Why on earth would you do this? I thought Dan’s opening up CSL
development with the repository was a big step forward. If I understand
you right, this, it seems to me, would be another two steps back.
I’m a little surprised by this decision to dedicate what I imagine is a
fair bit of your time to implementing this, since it sounds to me you’re
saying the styles will only be:
a) local to a particular user and database
b) specific to a single language
… when there’s still a lot of room to incrementally enhance csledit.xul.
OTOH, is there some reason you couldn’t just use the tool to do a batch
conversion of a few hundred styles and get volunteers to bring them up
to best practice standards as needed, make them available in the
repository, etc.?
Maybe along with that offer a style conversion web service that
automatically can load the style for the contributing user?
Simply having the attribute in the schema wouldn’t really encourage this kind
of usage, since it’s much more awkward than the alternative, but I
don’t know what application it would have for styles that conform to
best practices.
We have three options on the schema end:
I’m agnostic on what to do, though lean towards 2 or 3. If there’s a
clear use case for the attribute other than this particular case, then
I’d lean stronger toward option 2.
Any other opinions?
Bruce
Why on earth would you do this? I thought Dan’s opening up CSL
development with the repository was a big step forward. If I
understand
you right, this, it seems to me, would be another two steps back.
Because it will be a while time before we have the kind of style
support that EndNote does, and from an end user’s perspective, Zotero
is much less useful if you can’t use Word integration to submit to the
journals you need to submit to. I know quite a few scientists who use
Zotero to retrieve their references, but then need to export back to
EndNote to write their papers. Remember, EndNote supposedly has 3000+
styles. While many are probably duplicates, it’s a huge advantage to
the end user to be able to use these.
I’m a little surprised by this decision to dedicate what I imagine
is a
fair bit of your time to implementing this, since it sounds to me
you’re
saying the styles will only be:a) local to a particular user and database
b) specific to a single language… when there’s still a lot of room to incrementally enhance
csledit.xul.
To users in the sciences, who are typically submitting to journals,
(b) doesn’t matter, and given that the EndNote styles are freely
available online and already on the hard drives of all of our users
migrating from EndNote, (a) isn’t much of an issue either. I agree
that there’s room to enhance csledit.xul, but by supporting EndNote
styles, we greatly increase the number of styles available to Zotero
with much less effort than would be required to write hundreds of
styles by hand. Eventually, we do hope to have a better CSL editor and
many more CSL-based styles available, but a suitable editor alone will
require far more effort than the EndNote converter, which took a few
hours a day over the course of a week.
OTOH, is there some reason you couldn’t just use the tool to do a
batch
conversion of a few hundred styles and get volunteers to bring them up
to best practice standards as needed, make them available in the
repository, etc.?Maybe along with that offer a style conversion web service that
automatically can load the style for the contributing user?
This is an idea that we have entertained and are still considering,
but unfortunately, if we are converting Thomson/ISI’s styles, there
are potential copyright issues involved that we would prefer to avoid.
If you’d like to take on the liability, you’re welcome to do this.
Simon
Simon Kornblith wrote:
Why on earth would you do this? I thought Dan’s opening up CSL
development with the repository was a big step forward. If I
understand
you right, this, it seems to me, would be another two steps back.Because it will be a while time before we have the kind of style
support that EndNote does, and from an end user’s perspective, Zotero
is much less useful if you can’t use Word integration to submit to the
journals you need to submit to. I know quite a few scientists who use
Zotero to retrieve their references, but then need to export back to
EndNote to write their papers. Remember, EndNote supposedly has 3000+
styles. While many are probably duplicates, it’s a huge advantage to
the end user to be able to use these.
It’s a huge advantage for us to be able to format our references for
specific journals without thought; no quarrel there.
But it doesn’t follow that allowing, and even encouraging, individual
users to use styles private to them is a good idea. That is what I’m
concerned about.
I’m a little surprised by this decision to dedicate what I imagine
is a
fair bit of your time to implementing this, since it sounds to me
you’re
saying the styles will only be:a) local to a particular user and database
b) specific to a single language… when there’s still a lot of room to incrementally enhance
csledit.xul.To users in the sciences, who are typically submitting to journals,
(b) doesn’t matter, and given that the EndNote styles are freely
available online and already on the hard drives of all of our users
migrating from EndNote, (a) isn’t much of an issue either. I agree
that there’s room to enhance csledit.xul, but by supporting EndNote
styles, we greatly increase the number of styles available to Zotero
with much less effort than would be required to write hundreds of
styles by hand.
Yeah, but what good are they if the resulting CSLs are not
distributable, editable (in the repository), etc.?
Eventually, we do hope to have a better CSL editor and
many more CSL-based styles available, but a suitable editor alone will
require far more effort than the EndNote converter, which took a few
hours a day over the course of a week.OTOH, is there some reason you couldn’t just use the tool to do a
batch
conversion of a few hundred styles and get volunteers to bring them up
to best practice standards as needed, make them available in the
repository, etc.?Maybe along with that offer a style conversion web service that
automatically can load the style for the contributing user?This is an idea that we have entertained and are still considering,
but unfortunately, if we are converting Thomson/ISI’s styles, there
are potential copyright issues involved that we would prefer to avoid.
Sure. But if you were concerned about this, why did you even bother with
Endnote? Why not BibTeX, which has a long tradition of openness, and
tons of styles (particularly in the sciences and math)?
Second, I’m not so sure about the rights issues; INAL. Perhaps the
copyright issues would not apply to a web service where individual users
uploaded the styles? Or perhaps they would? I have a feeling that an
extreme interpretation might say even converting the files at all is
some kind of legal violation.
Even more ugly: what happens if someone takes a converted style, and
modifies it? If we accept there might be copyright issues with
distributing the first, what about the second? Does this then risk a
pollution of open CSL styles by copyright-encumbered content?
Hmm … perhaps we need to talk to a lawyer 
Beyond that, my main concern is that I do not want to create two classes
of CSL styles: those that are buried in SQL and unavailable for wider
use, and those that are publicly available.
I might be wrong, but I have serious worry that this might be something
like a zero-sum game; e.g. that doing what you’re doing will in fact
undermine the future growth of publicly available CSL styles.
And, frankly, I’m again bothered by the tendency of your project to
implement features like this without any outside discussion. The only
reason you even raised the issue here is because you want a new
attribute. You haven’t even rolled out 1.02, with its very cool
one-click auto-installation of CSL files, and you’re already looking to
implement something in a way which on face value (e.g. based on what I
can glean from what you’ve said) sounds like it will be in conflict with
that approach and vision.
I’m not really saying don’t do it (as if that would have any effect
anyway), but I am asking that you guys see if there’s a way to address
my concerns, and maybe open up a public discussion of this issue on
zotero-dev. E.g. what’s the plan that gets us to, say, 1000 openly
available CSL styles?
Bruce
Sure. But if you were concerned about this, why did you even bother
with
Endnote? Why not BibTeX, which has a long tradition of openness, and
tons of styles (particularly in the sciences and math)?
Have you seen a BST file? Implementing BibTeX support would involve
rewriting much of LaTeX in JavaScript, which I’m really not up for,
and there’s really no way to convert BSTs to CSL’s. EndNote’s style
format, once you get past the binary shell, is really not that far off
from CSL, with prefix and suffix parameters, various disambiguation
options, etc.
Second, I’m not so sure about the rights issues; INAL. Perhaps the
copyright issues would not apply to a web service where individual
users
uploaded the styles? Or perhaps they would? I have a feeling that an
extreme interpretation might say even converting the files at all is
some kind of legal violation.
We are still consulting a lawyer about this, but my feeling is that
converting the files, like ripping a CD, is not a rights violation.
Whether distributing converted styles presents a rights issue depends
on whether it is possible to construct multiple EndNote style files
that represent a given style, among other things, which is somewhat
unclear to me. In any case, conversion seems less likely to provoke a
lawsuit.
Even more ugly: what happens if someone takes a converted style, and
modifies it? If we accept there might be copyright issues with
distributing the first, what about the second? Does this then risk a
pollution of open CSL styles by copyright-encumbered content?Hmm … perhaps we need to talk to a lawyer
We are doing that. I think that the amount of modification required to
make a converted style look like a handwritten CSL would probably be
sufficient to eliminate any copyright issues. While I could neaten
them up, at the moment, the converter generates absolutely hideous CSL
because there’s no real reason for it not to as long as the styles
will be private. Besides, pulling the EndNote CSL out of the database
would involve some tricks.
Beyond that, my main concern is that I do not want to create two
classes
of CSL styles: those that are buried in SQL and unavailable for wider
use, and those that are publicly available.
If it would make you more comfortable, I can store the EndNote file in
the DB and convert it at runtime, so it doesn’t really exist at all.
I might be wrong, but I have serious worry that this might be
something
like a zero-sum game; e.g. that doing what you’re doing will in fact
undermine the future growth of publicly available CSL styles.
My hunch is that those who are currently producing CSLs, inside and
outside of our project, will continue to do so. While our style
repository has expanded recently, thanks to the support of Julian and
a few others, it will be a long time before we reach EndNote’s level.
To get any kind of growth beyond this small group, as you know, we
need a nice graphical style editor, which presents some difficult UI
and programming issues.
If you want to propose potential UIs (which I’d be happy to discuss on
this list), or maybe even contribute some code, so that we can get a
style editor done faster, perhaps that could assuage these concerns? I
personally was thinking of something like Apple’s UI for setting the
date format on OS X, although certain issues like conditionals, groups
with delimiters, etc. are hard to model from a UI standpoint.
And, frankly, I’m again bothered by the tendency of your project to
implement features like this without any outside discussion. The only
reason you even raised the issue here is because you want a new
attribute. You haven’t even rolled out 1.02, with its very cool
one-click auto-installation of CSL files, and you’re already looking
to
implement something in a way which on face value (e.g. based on what I
can glean from what you’ve said) sounds like it will be in conflict
with
that approach and vision.
I am just as committed to CSL as you are, but I am also committed to
Zotero. The fact is, Zotero is much less useful if you can’t use it to
write your papers. I don’t see why you find interoperability with
EndNote styles to be in conflict with auto-installation of CSL files:
both are ways of expanding style support.
The discussion isn’t exactly private. There is a ticket on Trac (#704)
with a bit of discussion on it already. You are welcome to attach any
relevant comments there (you already have an account, IIRC), and we
will consider them. Ultimately, however, unnecessary bureaucracy is
detrimental to a project’s health.
I’m not really saying don’t do it (as if that would have any effect
anyway), but I am asking that you guys see if there’s a way to address
my concerns, and maybe open up a public discussion of this issue on
zotero-dev. E.g. what’s the plan that gets us to, say, 1000 openly
available CSL styles?
We don’t have the programmers to commit to that at the moment, which
is why we’re working on the EndNote converter. If this is your
concern, perhaps you could donate some styles yourself? It seems like
Julian’s been doing nearly all of the work on that front.
Simon
Simon–
We are doing that. I think that the amount of modification required to
make a converted style look like a handwritten CSL would probably be
sufficient to eliminate any copyright issues. While I could neaten
them up, at the moment, the converter generates absolutely hideous CSL
because there’s no real reason for it not to as long as the styles
will be private. Besides, pulling the EndNote CSL out of the database
would involve some tricks.
I looked at the 704 ticket discussion and it seems then that steps
could be taken for users to modify styles converted from Endnote, and
then contribute those copyright-free versions to the public
repository. Down the road, would it be possible to do any of this:
Allow users to load converted Endnote styles in csledit.xul (or a
future visual editor), edit them, and then contribute to the public
Zotero CSL repository
Use a dialogue on conversion that determines whether a style is
user-developed (i.e. in a desktop version of Endnote) vs. Thompson’s
and then give users an option to contribute their own styles to the
public repository right away. Some Endnote users modify styles in
Endnote to create their own, and those would presumably be copyright-
free at the outset.
Perhaps generate a less hideous CSL that is more easily editable
to encourage such contributions (but I understand that will take more
time)
I’m curious–how do you match Endnote and Zotero item types on
conversion? Or do you just convert major item types like book, book
section, and journal/magazine/newspaper articles? It seems that when
hierarchical and custom item types are implemented (and perhaps even
now) all styles converted from Endnote would need to be user-editable
to allow for formatting of Zotero-specific item types.
It may be useful to have a dialogue that tells a user on conversion
if a public Zotero style for the same journal/standard (with better
support for Zotero item types) is available. This way new users will
be prevented from adding a style they have used in Endnote if a
better Zotero style exists.
Many thanks for your work on this.
Best,
Elena
Simon–
We are doing that. I think that the amount of modification required
to
make a converted style look like a handwritten CSL would probably be
sufficient to eliminate any copyright issues. While I could neaten
them up, at the moment, the converter generates absolutely hideous
CSL
because there’s no real reason for it not to as long as the styles
will be private. Besides, pulling the EndNote CSL out of the database
would involve some tricks.I looked at the 704 ticket discussion and it seems then that steps
could be taken for users to modify styles converted from Endnote, and
then contribute those copyright-free versions to the public
repository. Down the road, would it be possible to do any of this:
- Allow users to load converted Endnote styles in csledit.xul (or a
future visual editor), edit them, and then contribute to the public
Zotero CSL repository
This would be easy to implement, although we should further
investigate the possible legal issues first.
- Use a dialogue on conversion that determines whether a style is
user-developed (i.e. in a desktop version of Endnote) vs. Thompson’s
and then give users an option to contribute their own styles to the
public repository right away. Some Endnote users modify styles in
Endnote to create their own, and those would presumably be copyright-
free at the outset.
This is a good idea. We could simply use a list of Thomson’s styles to
ensure that the user isn’t contributing one, I suppose.
- Perhaps generate a less hideous CSL that is more easily editable
to encourage such contributions (but I understand that will take more
time)
If we go this route, I’d create a tool to clean up any CSL, since it
would be more useful than tying this to the EndNote converter. There
will still be some messiness, since EndNote uses separate definitions
for every item type, which results in some additional complexity.
I’m curious–how do you match Endnote and Zotero item types on
conversion? Or do you just convert major item types like book, book
section, and journal/magazine/newspaper articles? It seems that when
hierarchical and custom item types are implemented (and perhaps even
now) all styles converted from Endnote would need to be user-editable
to allow for formatting of Zotero-specific item types.
Not all item types and variables can be mapped. Right now, I map:
Journal Article
Newspaper Article
Magazine Article
Electronic Article
Book
Edited Book
Electronic Book
Book Section
Thesis
Personal Communication
Report
Map
Graphic
Patent
Web Page
Bill
Case
Manuscript
Film or Broadcast
Figure
Conference Paper
Legal Rule or Regulation
Dictionary Entry
Encyclopedia Entry
We also map the EndNote “Generic” entry, which gets applied to all
other item types.
I don’t map:
Conference Proceedings
Computer Program
Audiovisual Material
Hearing
Statute
Chart or Table
Equation
Online Database
Online Multimedia
Government Document
Classical Work
Unpublished Work
Ancient Text
Grant
Is it really impossible to cite conference proceedings in CSL, or am I
missing something? Are any of these other types useful to us?
It may be useful to have a dialogue that tells a user on conversion
if a public Zotero style for the same journal/standard (with better
support for Zotero item types) is available. This way new users will
be prevented from adding a style they have used in Endnote if a
better Zotero style exists.
This is also a good idea, but might be a little tricky. I’ll talk to
Dan about implementing it.
Simon
Bruce–
Beyond that, my main concern is that I do not want to create two
classes
of CSL styles: those that are buried in SQL and unavailable for wider
use, and those that are publicly available.I might be wrong, but I have serious worry that this might be
something
like a zero-sum game; e.g. that doing what you’re doing will in fact
undermine the future growth of publicly available CSL styles.
I think if there is a way for users to modify and contribute Endnote
styles to the public repository (see my previous message on this)
this will not be an issue.
And, frankly, I’m again bothered by the tendency of your project to
implement features like this without any outside discussion. The only
reason you even raised the issue here is because you want a new
attribute. You haven’t even rolled out 1.02, with its very cool
one-click auto-installation of CSL files, and you’re already
looking to
implement something in a way which on face value (e.g. based on what I
can glean from what you’ve said) sounds like it will be in conflict
with
that approach and vision.I’m not really saying don’t do it (as if that would have any effect
anyway), but I am asking that you guys see if there’s a way to address
my concerns, and maybe open up a public discussion of this issue on
zotero-dev. E.g. what’s the plan that gets us to, say, 1000 openly
available CSL styles?
Well, what is your plan that gets us to 1000 openly available CSL
styles?
Realistically, the CSL project would not be moving forward at the
current pace if Zotero developers/users weren’t working on it–are
there CSL developers not visible on this list who are working away on
the styles and the schema? If not, the opposition of “your
project” (Zotero) vs. “my project” (CSL project owned by Bruce)
doesn’t really make sense to me.
Best,
Elena> Bruce
I don’t map:
Conference Proceedings
Computer Program
Audiovisual Material
Hearing
Statute
Chart or Table
Equation
Online Database
Online Multimedia
Government Document
Classical Work
Unpublished Work
Ancient Text
GrantIs it really impossible to cite conference proceedings in CSL, or am I
missing something? Are any of these other types useful to us?
From fields available in a trial version of Endnote X1 for Mac, it
seems that the mapping is as follows:
[Endnote > Zotero > CSL]
Conference Paper > Conference Paper > chapter
Conference Proceedings > Presentation > paper-conference
I.e, what they call “conference proceedings” is actually a conference
presentation, and what they call “conference paper” is a paper
published in conference proceedings.
But this may be different from previous versions of Endnote. Which
version should I be looking at?
Other useful types may be (if the mapping works):
[Endnote > CSL]
Unpublished work > manuscript
Government Document > report
Audiovisual material, Hearing, and Statute seem important (and have
Zotero equivalents) but CSL doesn’t seem to support them, so I’m not
sure what to do about that.
Elena
Simon Kornblith wrote:
Sure. But if you were concerned about this, why did you even bother
with
Endnote? Why not BibTeX, which has a long tradition of openness, and
tons of styles (particularly in the sciences and math)?Have you seen a BST file? Implementing BibTeX support would involve
rewriting much of LaTeX in JavaScript, which I’m really not up for,
and there’s really no way to convert BSTs to CSL’s. EndNote’s style
format, once you get past the binary shell, is really not that far off
from CSL, with prefix and suffix parameters, various disambiguation
options, etc.
Yeah, fair enough.
…
We are doing that. I think that the amount of modification required to
make a converted style look like a handwritten CSL would probably be
sufficient to eliminate any copyright issues. While I could neaten
them up, at the moment, the converter generates absolutely hideous CSL
because there’s no real reason for it not to as long as the styles
will be private. Besides, pulling the EndNote CSL out of the database
would involve some tricks.Beyond that, my main concern is that I do not want to create two
classes
of CSL styles: those that are buried in SQL and unavailable for wider
use, and those that are publicly available.If it would make you more comfortable, I can store the EndNote file in
the DB and convert it at runtime, so it doesn’t really exist at all.
That might be better in the short-run, though if you can figure out a
way to get good CSL files that can be openly distributed, that would be
ideal.
…
I am just as committed to CSL as you are, but I am also committed to
Zotero. The fact is, Zotero is much less useful if you can’t use it to
write your papers. I don’t see why you find interoperability with
EndNote styles to be in conflict with auto-installation of CSL files:
both are ways of expanding style support.
I have no problem with converting Endnote styles to CSL. I just want
those styles to then be freely available.
The problem point I see is: what incentive do users have to submit or
enhance CSL files if they just download Endnote ones?
The discussion isn’t exactly private. There is a ticket on Trac (#704)
with a bit of discussion on it already. You are welcome to attach any
relevant comments there (you already have an account, IIRC), and we
will consider them. Ultimately, however, unnecessary bureaucracy is
detrimental to a project’s health.
Sure, but suggesting that it’s a good idea for you guys to layout
roadmaps and discuss important new features in public is hardly
“unnecessary bureaucracy”; it’s how any viable free software project
works and succeeds.
I’m not really saying don’t do it (as if that would have any effect
anyway), but I am asking that you guys see if there’s a way to address
my concerns, and maybe open up a public discussion of this issue on
zotero-dev. E.g. what’s the plan that gets us to, say, 1000 openly
available CSL styles?We don’t have the programmers to commit to that at the moment, which
is why we’re working on the EndNote converter. If this is your
concern, perhaps you could donate some styles yourself?
It seems like Julian’s been doing nearly all of the work on that front.
I’m not putting this in your lap; I’m saying what’s the (collective)
plan to get there? What are the steps we all need to take to get to that
endpoint?
Obviously creating and enhancing CSL was an excellent first step, and
Zotero opening up the styles repository was an excellent second step.
But how do we now get from here to that endpoint of a dramatically
larger set of freely available styles. It seems this discussion
clarifies some of that, but I’d just suggest keeping this goal in mind.
Bruce
Elena,
Elena Razlogova wrote:
Bruce–
Beyond that, my main concern is that I do not want to create two
classes
of CSL styles: those that are buried in SQL and unavailable for wider
use, and those that are publicly available.I might be wrong, but I have serious worry that this might be
something
like a zero-sum game; e.g. that doing what you’re doing will in fact
undermine the future growth of publicly available CSL styles.I think if there is a way for users to modify and contribute Endnote
styles to the public repository (see my previous message on this)
this will not be an issue.
Yes, this is the key point, and I think your suggestions toward that end
were good. If we can find a way to do this, then there’s no problem at all.
And, frankly, I’m again bothered by the tendency of your project to
implement features like this without any outside discussion. The only
reason you even raised the issue here is because you want a new
attribute. You haven’t even rolled out 1.02, with its very cool
one-click auto-installation of CSL files, and you’re already
looking to
implement something in a way which on face value (e.g. based on what I
can glean from what you’ve said) sounds like it will be in conflict
with
that approach and vision.I’m not really saying don’t do it (as if that would have any effect
anyway), but I am asking that you guys see if there’s a way to address
my concerns, and maybe open up a public discussion of this issue on
zotero-dev. E.g. what’s the plan that gets us to, say, 1000 openly
available CSL styles?Well, what is your plan that gets us to 1000 openly available CSL
styles?
I think the discussion has clarified that. The key is to find a way to
build up the public repository, as you note. And, of course, we need
someone, somewhere, to finish a good editor.
The rather unfortunate reality is the more powerful CSL has become, the
more difficult it is to implement in a GUI. There’s still some features
I’d like to add back in (like grouped lists), that would further that trend.
Realistically, the CSL project would not be moving forward at the
current pace if Zotero developers/users weren’t working on it–
Sure.
are there CSL developers not visible on this list who are working away on
the styles and the schema? If not, the opposition of “your
project” (Zotero) vs. “my project” (CSL project owned by Bruce)
doesn’t really make sense to me.
There are other developers working on CSL implementations, and I just
heard from another today. And there are still others contemplating
implementing it.
To the degree that anyone is interested in CSL, it’s largely for the
promise of a free and independent language; one that, once we get over
the hump of increasing the number of available styles and making it
easier for people to create new ones, can benefit from the viral nature
of the internet. We’re just trying to solve the chicken-and-egg problem
to our collective benefit!
And these are two different projects, with two different project
leads. There’s going to at times be communication issues; no big deal.
Bruce