@Charles, it would e.g. be relatively simple to convert all our
dependent styles to independent styles when we transfer them to
GitHub - citation-style-language/styles-distribution: Official repository for distribution of validated CSL citation styles.. That
would free the CSL software products from having to look up the parent
styles, but it would complicate contributions to the CSL style
repository, since users would start to modify and submit changes to
those monolithic, formerly dependent styles.
@Bruce, Frank, is there really a need for a general extension
mechanism?
I don’t know. I’m just holding out some hope that proper legal styles can
one day be brought to CSL.
I think it would be of limited use if it only covers XML
attributes. And wouldn’t an uncontrolled extension mechanism encourage
forking of CSL? How would we deal with arbitrary style extensions that
are submitted to the style repository? I would also like to stress
that CSL can already be extended through an extension schema, as we
did for Frank’s CSL-m fork
(https://github.com/fbennett/schema/blob/master/csl-mlz.rnc), although
that of course breaks compatibility with the regular CSL schema.
Yes, but it locks the variant styles out of the circle permanently. If that
is the way forward, CSL-m will stand to get more traction if it is called
something else.
Rintze - the problem we have is this is a thread with like 40 messages, but
still not a lot of clarity.
Not sure how we fix this.
Rintze - the problem we have is this is a thread with like 40 messages,
but still not a lot of clarity.
Not sure how we fix this.
Perhaps it was all just too complicated.
I’ll just extend the variant schema.
Thanks to all for time spent on the style selection issue.
-end-of-thread-
this seems quite unsatisfactory to me. Principally, because it seems like
Frank ended up throwing up his hands in frustration, which is bad on
multiple levels. Also, because I agree with him that our goal should be to
incorporate legal support into CSL, and to those of us who have read
through his blog post or list post (or both) on the topic it’s quite clear
that’s not going to happen without some version of modularity and we might
as well figure out how we want that to work now. (Modularity at a general
level would be nice, but we’re doing just OK without–it’s really the
insane requirements of legal citations that make this a necessity).
So, maybe we can take another stab at this tomorrow?
(I also wonder more generally how we can make discussion of such proposals
more efficient and less frustrating for the person proposing them).
this seems quite unsatisfactory to me. Principally, because it seems like
Frank ended up throwing up his hands in frustration, which is bad on
multiple levels. Also, because I agree with him that our goal should be to
incorporate legal support into CSL, and to those of us who have read through
his blog post or list post (or both) on the topic it’s quite clear that’s
not going to happen without some version of modularity and we might as well
figure out how we want that to work now. (Modularity at a general level
would be nice, but we’re doing just OK without–it’s really the insane
requirements of legal citations that make this a necessity).
So, maybe we can take another stab at this tomorrow?
(I also wonder more generally how we can make discussion of such proposals
more efficient and less frustrating for the person proposing them).
It’s not necessarily a bad thing, and there is no ill will. To get
legal support going at the desktop level, we’ll need to get people
from legal tech circles involved, because they know the style
requirements and will have an incentive to pitch in there. That won’t
happen until there is a coherent picture in the client, MLZ/CSL-m
branding is a mess at the moment - it’s a clutter of project names and
websites that I made up on the fly while pulling things together. If I
were a user, I would find it all a little off-putting.
Now with the kit all working is probably a good time for me to think
about presentation issues, and get a more comfortable watering-hole
and workflow in place. Nothing will change; there can still be
cross-pollination between projects, I’ll keep pulling from Zotero and
CSL, and we can still keep an eye on compatibility. I’ll just be
trying to present a more coherent picture to potential users on the
legal side, an let developments there take their natural course.
Maybe, it helps to see each others attitude to the general questions raised
here. I put together a poll for that:
https://terminplaner2.dfn.de/foodle/xbiblio-devel-Macro-condition-54f2e?language=en
(I hope that is more comfortable than another 8 emails).2015-03-01 2:21 GMT+01:00 Frank Bennett <@Frank_Bennett>:
Hi,
I’m jumping mid-thread - I’m on holiday without good Internet access,
so I might not answer quickly.
I just wanted to mention two semi-offtopic things:
a) I’d really like to move some of the CSL-m features into CSL
upstream… specially multi-lingual bibliographies.
b) If we supported macros “out-of-the-style” as Charles Parnott said
the implementors should resolve the dependencies (like I think that all
do with the dependent styles: no implementor asks the user to fetch
other styles manually). Like, when referring to a macro, using a URI.
Or, another idea (I haven’t read all the emails carefuly) we could
create a CSL macro language. So one could have the macros “directory”,
the “styles directory” (with a macro language that would say “include
macro01 code here” or “include macro02 here”) and would generate the
final CSL files based on that. I’m not sure if this would solve the CSL
legal problems or not, or perhaps only minor changes would be required
(besides the macro language).
And that’s my 2p.
A 2015-02-28 01:35, Charles Parnot escrigué:
Thanks for attempting to move the discussion forward Phillip.
But I don’t think these questions actually capture the issues some of
us are raising; they don’t really capture the tensions of different
paths. So I’m not going to answer it.
The one thing I agree is worth discussing is medium and form of
communication around these proposals. Towards that end, a Google Doc
of a proposed standardized template for proposals:
Feel free to add comments or suggestions. Note that Google recently
added a “suggesting” mode that works like standard change-tracking.
Perhaps one way forward generally is to use Google Docs to flesh out a
proposal (ask questions, clarify language, etc.) and only once it’s
clear move it to some other place (the issue tracker and/or here?)?
Bruce
The basic objective of a proposal can typically be stated in a few words:
- To support configurable trigraph styles
- To support “composite” citation styles
- To support multilingual citations
- To support legal referencing
Given that CSL is a very solid language for the things that it does,
most proposals to change or extend it will be driven by some
compelling project need that cannot be avoided. The first thing a
proposer wants from CSL is a decision on whether the group is
committed to accommodating the basic requirement that he or she is
faced with.
If the ultimate decision on commitment in CSL is conditioned on the
proposer putting forward a roadmap that the group finds satisfactory,
that may be a big risk for them to assume: they will not have a very
strong incentive to engage with the process.
Frank
The basic objective of a proposal can typically be stated in a few words:
- To support configurable trigraph styles
- To support “composite” citation styles
- To support multilingual citations
- To support legal referencing
Given that CSL is a very solid language for the things that it does,
most proposals to change or extend it will be driven by some
compelling project need that cannot be avoided. The first thing a
proposer wants from CSL is a decision on whether the group is
committed to accommodating the basic requirement that he or she is
faced with.
If the ultimate decision on commitment in CSL is conditioned on the
proposer putting forward a roadmap that the group finds satisfactory,
that may be a big risk for them to assume: they will not have a very
strong incentive to engage with the process.
True. Perhaps it could be a staged process?
Bruce
But also, even with the proposed template, I would want to limit the
actual content in terms of word length; for the proposals to concisely
cover both the specific suggested changes, as well as the broader
implications.
As in, each section would be a short-to-medium paragraph, I imagine.
The thing is, it’s hard to assess whether a change is worth supporting
without understanding the costs.
This isn’t related to the original issue, which I’ve withdrawn. It
might be good to start a separate thread on proposal submission
requirements.
Frank
Well, the thread wasn’t completely useless, right? Despite being
frustrating for Frank, we’re now aware of the issue he brought up,
have tried defining the problem and have come up with a few possible
solutions. (even though the thread went off-topic, no decision was
made on inclusion of the feature in standard CSL, and Frank has chosen
to implement his original proposal)
With CSL 1.0 and 1.0.1, Frank and I hashed out a lot of CSL changes
behind the scenes, and then presented a rather polished proposal to
the mailing list. Often chat would be much more productive than
(group) email. It might help us if we had a place to ruminate and
polish proposals off-list. The mailing list is a poor archive for
ideas, and proposals tend to go easily off-track.
Perhaps a “proposals” CSL GitHub repository for all CSL feature
requests and proposals? We could use the issue tracker and
subdirectories in that repo to flesh out the details, come up with
implementation ideas, examples, and documentation. We could use
Bruce’s template as a start.
We could then limit use of the mailing list to mostly present and vote
on (draft) proposals.
Rintze