On Sep 10, 2012, at 7:46 PM, Rintze Zelle wrote: > - Several sites have started offering citeproc-JSON: see e.g. > http://blog.bibsonomy.org/2012/07/feature-of-week-citation-style-language.html > , http://www.doi.org/doi_handbook/5_Applications.html#5.4.1 and > http://crosscite.org/cn/#sec-4-1 . I think we could improve the > consistency of CSL style output between implementations by writing > better documentation on input expectations. This covers: > * date formats. Bruce seems to be a big proponent of adopting the > Extended Date/Time Format as much as possible (EDTF, see > http://www.loc.gov/standards/datetime/ ) > * name parsing (e.g. extracting non-dropping and dropping particles > from two-field names)
Name parsing should strictly be optional; I've written a name parser for citeproc-ruby to deal with single-field names, but because of language / cultural differences this can quickly become infeasible. In some languages, for example, even word segmentation alone is a hard problem. I've gone to great lengths to support names passed in a single field; IIRC Frank even handles Japanese names specifically – but I would be careful to make it mandatory for CSL processors to implement such features as it sets the bar pretty high. > * field assignments (which item type should, or shouldn't, have > which fields). Aurimas prepared a map for Zotero: > http://aurimasv.github.com/z2csl/typeMap.xml . It would be great if we > could standardize the fields exposed to the CSL processors among the > different reference managers (on a per item type basis). My hope is > that we can clean up Zotero's metadata model in the coming year > (tickets as compiled by the Zotero user community can be found at > https://github.com/ajlyon/zotero-bits/issues ), and offer the result > as a guideline for other reference managers. > * the JSON schemas. These could use some documentation. I would agree that the data/input format should receive more attention in the future. A few months ago, I recorded a some observations about the format here: https://github.com/citation-style-language/schema/wiki/Processor-input-%28JSON%29 > - One of the things I'd really like to see is an improved CSL test > suite. Sylvester posted a Cucumber mockup format a while back ( > https://github.com/inukshuk/citeproc-ruby/blob/1c420de0f7a86b7c35782dee86ce62cbebb47ab9/features/condition/is_numeric.feature > ). I never had much success adding styles to the current test suite > setup, and I really would like to be able to categorize tests (e.g. on > CSL version, and on the CSL feature that is being tested). If the > infrastructure is there, I wouldn't mind annotating the existing tests > by hand. I'm still working on the rewrite of citeproc-ruby; I've made good progress over the summer and I'm currently able to test individual rendering elements in isolation. Once I move on to the point where I can work with integration and acceptance type of tests, I intent to continue the work in the csl-test-suite package. The plan, right now, is to use Cucumber, because I think it offers a number of features that we need, but make it a priority for the tests to be convertible to the current JSON format so that other implementations can use the tests without having to make any changes. Sylvester
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
