> I agree. Some ideas for further improvements: > - we have metadata for several publishers, but as journals get added, > renamed, or discontinued, we need to update it. We could do this > ourselves periodically, e.g. once a year (several publishers publish > their journal metadata online). It is probably also worthwhile to > clarify our documentation on contributing styles to let users (and > publishers) know that we have publisher-specific metadata, and that if > they want to add/rename/delete a style from one of these publishers, > they don't need to bother with touching CSL XML. > - the current script does an admirable job of creating dependents. It > also allows us to suppress the creation of discontinued/renamed styles > (via a "skip list"). What it doesn't do, however, is provide a way to > identify dependent styles from the repository that are outdated and > should be removed. It would be enough if the script, after freshly > generating all its dependents, would check if there are any > script-generated dependents in the styles repository that aren't > present in the fresh batch (script-generated styles are easily > identifiable via the XML comment we add to each of them). We can then > delete those by hand. > > Rintze
Yes, better integration with the actual repository would be nice. At the moment, all the script does is generate those styles and then one has to manually copy them into the repo. There are in fact 3 issues with this: - if a style has not changed, the script will still create a new style, with an updated date, and simply copying over into the repo will create a needless update. I deal with this easily for now, by just using the Github.app and quickly going through each file to spot the one that really changed, and only tick those for the commit. It works but obvisouly error-prone and it gets old quickly - discontinued journals, as you indicate. for this, we could simply add a '_discontinued.txt' list, which is distinct from the `_skip.txt` list (as this one is for journals we are not yet sure what to do with, or maybe that are exceptions etc…). In both cases, the script will need to look into the actual repo to manipulate things in there as well. This is the next step, and obvisouly something I was not comfortable doing automatically until it was clear we have something solid. Which I think we have at this point. Manual inspection of the result before committing the changes, and proper validation, are still necessary, of course. Charles ------------------------------------------------------------------------------ Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
