> One question: how would you ensure quality (and uniqueness)? By manually verifying the entry (hence the requirement to include a link to e.g. the instructions to authors). But then, that was also in fact why I posted this to you guys first. How do you judge that?
In any case, we don't expect a huge number of styles, even a few dozens would be a great success. We'll see: if we are overwhelmed, that will be a good problem to have for us (Mekentosj) and for everybody, isn't it? > It's a minor niggle, but please always first use the full "Citation Style > Language" name before abbreviating to "CSL". Ah, good point, totally agreed! I'll make that change before we post the thing. > Another requirement I would add is to clearly mention that only styles that > are valid CSL 1.0 will be considered for inclusion in the style repository > (which also means no Papers2-specific CSL variables). Yes, though it's part of the CSL rules for submitting new styles, and I point to the CSL wiki for that. But to be clear, I have added that specific requirements to the text we would post. > I'm not sure you should require an email address. I personally have always > been hesitant to include mine out of fear for spam. I'll leave it as is, because I do think anybody who posts something for others to use needs to take responsibility, so we'll call that the Mekentosj' requirement ;-) I think that can be part of that quality issue you also raised. Of course, if somebody is reluctant to add their email, I'll bend the rules... > I'm happy for Charles to have commit access - that seems like the most…<snip> I'd be happy with that, then. I only have 5 styles added to Papers2, and contributed by users (and me). So that will be a first interesting trial. I'll do that when I am back to work, though, after the 24th. Same for the fixtures. Some might be useful for you guys too, I'll be sure to only add relevant ones. Let me know if/when I get commit access, then. > As for the papers specific variables you added - I believe PMID and PMCID are > planned so those could just be mapped back to generic csl variables once > they're introduced. That would be awesome, great! Bruce mentioned I should add that to the feature requests, I'll have to look into that. > Is there any reason you're not mapping papers_note to "note"? I was worried about this, because we already have the problem with BibTeX users, that actually use 'note' for inclusion in the bibliography. Typically, Papers2 notes are longer, more like quick personal notes and thoughts on a paper, and not relevant at all for a bibliography. In this case, this is thus more a convenient way for users to spit out all their notes in combination with a reference. I only added this one because of **one** user request. > We would need confirmation from at least Frank (citeproc-js), Charles > (Papers2 CSL processor), Sylvester (citeproc-rb) and Andrea (citeproc-hs) > that such a change in our release workflow won't give problems, though. (are > there any other CSL processors used in production settings that I missed?) Unknown variables and unknown attributes are handled "gracefully" on my end, as they are simply ignored. Thinking about CSL versioning and how to handle transitions: aren't implementations supposed to check the version number and then could decide not to use a style if in a version more recent than they support? For instance, I could imagine that I would change my implementation now to ignore any styles higher than 1.0 (right now, it's blissfully ignoring the version!), so that it won't even allow newer styles to be used, maybe with some error message to the user. Alternatively, if we know now that subpoint release are backwards-compatible, except for new variables and attributes, I could decide to support up to 1.0.x, but then leave out anything at 1.1 or higher. Maybe to know what's the best approach, we need to go through one such transition with some basic rules in mind, see how it goes, then learn from that for the next transition. Charles -- Charles Parnot [email protected] twitter: @cparnot http://mekentosj.com ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
