On Thu, Mar 28, 2013 at 12:08 AM, Sebastian Karcher <[email protected]> wrote: >> I also would like to disallow having two (or more) instances of cs:issn, >> since generally one should be a cs:eissn. > just so I understand this correctly: One eissn and one issn would still be > OK, yes. You just don't want two cs:issn elements - correct?
Yes. The cs:eissn element was only recently introduced in CSL 1.0.1, so many existing styles used cs:issn for both the online and print ISSNs. It's obviously preferable to mark the online ISSN with cs:eissn. Also, I don't really care for storing ISSN-L identifiers (with cs:issnl), and have even gone as far as deleting these from styles. They haven't really caught on as a way to replace print and online ISSNs, and are redundant if we already have the latter (since the ISSN-L always seems to match one of those two). On Thu, Mar 28, 2013 at 5:28 AM, Charles Parnot <[email protected]> wrote: > Regarding the script: it's a nice way to maintain dependent style in a more > controlled way. Even if updating the journal list (in tab-delimited text > files) and running the script can sometimes take longer than tweaking the one > affected style, it's still worth the extra effort, as it means better > maintained dependent in the future. I wonder if this logic could be pushed > further in the future, by having an even easier way to edit the dependent > list without having to touch any of the XML directly. 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 ------------------------------------------------------------------------------ Own the Future-Intel® 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://p.sf.net/sfu/intel_levelupd2d _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
