Hello, I've been doing some work on my citeproc-py (https://github.com/brechtm/citeproc-py) and have written down some questions/remarks about some of the tests and the CSL spec. Note that I could simply be misunderstanding/misinterpreting things for some of these.
* the CSL spec is contradictory about number detection >>> Tests whether the given variables **contain numeric content**. versus >>> Content is considered numeric if it **solely consists of numbers**. >>> For example, "2nd" tests "true" whereas "second" and "2nd edition" >>> test "false". does not seem to agree with condition_IsNumeric * Chicago page range format: what do do with five or more digits? * Which values are allowed for the "page" input field? I see multiple ranges can also be specified. I think the CSL spec should, in general, also define the format of the input fields. Personally, I would opt for a structured format (like the date fields) as opposed to a string-format (the page field). Individual CSL processors can still convert a string-formatted field to the structured data. This would require changes to the tests. * Shouldn't "page-first" be a number variable? It is used with number in page_NumberPageFirst * The spec doesn't say anything about the nested groups special case. variables_TitleShortOnShortTitleNoTitleCondition seems to disagree with the CSL spec: >>> cs:group and its child elements are suppressed if a) at least one >>> renderingelement in cs:group calls a variable (either directly or via >>> a macro), and b)all variables that are called are empty. In the group in the else section only the title variable is called. For ITEM-3, this variable is empty, so the group should be suppressed, but it isn't. Should a nested group always act as if it's (successfully) calling a variable? If so, the spec should mention this. * I seem to remember citeproc-js postprocesses its output to remove duplicate affixes. The CSL spec doesn't say anything about this, AFAIK. What's the official stance on this? I would personally avoid doing this, unless the spec includes an unambiguous definition on how this should work. * locale_TitleCaseGarbageLangEnglishLocale: is "en" a valid locale? If so, and default-locale="en", which locale should we use? * textcase_SkipNameParticlesInTitleCase (1): I believe this behavior is not part of the CSL spec, is it? * textcase_SkipNameParticlesInTitleCase (2): the result doesn't seem to follow the CSL spec. The 'a' after the colon should be capitalized: >>> In both cases, stop words are lowercased, unless they are the first or >>> lastword in the string, or follow a colon. * date_VariousInvalidDates: why is 'Spring' in the output? * page_Chicago: is the example S input data correct? It strikes me as a confusing way of representing a page range (in addition to saving only a single digit). * A large number of tests test functionality that is not in the CSL spec, but is provided by citeproc-js (raw dates, static ordering, literal names, ...). I think these should be indicated as such, or perhaps moved to a separate directory. This would make it easier to check the other CSL processor's compatibility. I hope you can find the time to answer these. Thanks, Brecht ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
