re roman numerals: treating them as text works for CMoS which always wants
full page ranges for roman numbers.
On Thu, Aug 8, 2013 at 2:46 PM, Sebastian Karcher <
[email protected]> wrote:
> CMoS page range specs don't change for ranges with more than 4 digits,
> i.e. "Use two digits unless more are needed to include all changed parts"
> 12345-46
> 12345-678
> 12345-6789
>
> and the different rules for multiples of hundred and the first nine digits
> thereafter remain,
> i.e. cite all digits when dealing with multiples of hundred
> 12300-12345
> and only the changed digit(s) for the first ten thereafter
> 12301-8
>
>
>
> On Thu, Aug 8, 2013 at 2:05 PM, David Lawrence <[email protected]>wrote:
>
>> Re: Page range
>>
>> The fore-matter in books and some journals is usually in Roman numerals.
>> Is this observation relevant?
>>
>>
>> David
>>
>>
>>
>> On Thu, Aug 8, 2013 at 12:27 PM, Rintze Zelle <[email protected]>wrote:
>>
>>> On Thu, Aug 8, 2013 at 1:12 PM, Brecht Machiels <[email protected]>
>>> wrote:
>>> > * 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
>>>
>>> The behavior of "is-numeric" changed in CSL 1.0.1. See
>>> http://citationstyles.org/downloads/release-notes-csl101.html#numbers
>>>
>>> I can see how the current description in the specification might be
>>> somewhat confusing, but it is meant to agree with
>>>
>>> https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/condition_IsNumeric.txt
>>> .
>>> In "Tests whether the given variables contain numeric content."
>>> (http://citationstyles.org/downloads/specification.html#choose), I
>>> mean to say that the test is against the entire string contents of
>>> each variable. In a string like "2nd edition", the "edition" substring
>>> means that the entire string is non-numeric.
>>>
>>> > * Chicago page range format: what do do with five or more digits?
>>>
>>> The specification currently links to
>>> http://www.aahn.org/guidelines.html, but it seems like the content we
>>> relied on moved to http://www.aahn.org/stylesheet.html . The latter
>>> page shows an excerpt from CMoS that we almost copied verbatim.
>>> Sebastian, could you check if CMoS 16th edition gives any guidance on
>>> number ranges of 5 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.
>>>
>>> This would presumably involve describing the JSON format used by
>>> citeproc-js in more detail. See
>>> http://blog.martinfenner.org/2013/08/08/csl-is-more-than-citation-styles/
>>> for a relevant discussion on this topic.
>>>
>>> > * Shouldn't "page-first" be a number variable? It is used with number
>>> in
>>> > page_NumberPageFirst
>>>
>>> See https://github.com/citation-style-language/schema/issues/9. I
>>> think Frank prefers to render "page" and "page-first" with cs:number,
>>> but that's currently not kosher CSL.
>>>
>>> > * 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 think Frank already has an opinion on this, but I can't find the
>>> discussion. I think the test
>>> (
>>> https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/variables_TitleShortOnShortTitleNoTitleCondition.txt
>>> )
>>> describes the desired behavior, in which case the specification should
>>> indeed be amended. This is somewhat related to the open issue
>>> https://github.com/citation-style-language/schema/issues/104
>>>
>>> > * 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.
>>>
>>> I'm convinced that CSL processors need to do some suppression of
>>> duplicated punctuation. Frank just prepared some tests that describe
>>> the current behavior in citeproc-js, and I hope to write up some
>>> requirements for the specification in the next few weeks based on
>>> those. See
>>>
>>>
>>> https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/punctuation_FullMontyPlain.txt
>>>
>>> https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/punctuation_FullMontyQuotesIn.txt
>>>
>>> https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/punctuation_FullMontyQuotesOut.txt
>>>
>>> https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/punctuation_FullMontyField.txt
>>>
>>> > * locale_TitleCaseGarbageLangEnglishLocale: is "en" a valid locale? If
>>> so,
>>> > and default-locale="en", which locale should we use?
>>>
>>> http://citationstyles.org/downloads/specification.html#locale-fallback
>>> discusses this: "If the chosen output locale is a language (e.g.
>>> "de"), the (primary) dialect is used in step 1 (e.g. "de-DE")."
>>>
>>> The table above that line mentions that "en-US" is the primary dialect
>>> for "en".
>>>
>>> > * textcase_SkipNameParticlesInTitleCase (1): I believe this behavior is
>>> > not part of the CSL spec, is it?
>>>
>>>
>>> https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/textcase_SkipNameParticlesInTitleCase.txt
>>>
>>> Correct.
>>>
>>> > * 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.
>>>
>>> It seems like it should
>>> (
>>> http://citationstyles.org/downloads/specification.html#title-case-conversion
>>> ).
>>> Frank?
>>>
>>> > * date_VariousInvalidDates: why is 'Spring' in the output?
>>>
>>>
>>> https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/date_VariousInvalidDates.txt
>>>
>>> Don't know. I think you can ignore this unit test. Frank?
>>>
>>> > * 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).
>>>
>>>
>>> https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/page_Chicago.txt
>>>
>>> Looks unambiguous to me.
>>>
>>> > * 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.
>>>
>>> Sylvester Keil proposed using a Cucumber format for unit tests, which
>>> would allow tests to be tagged:
>>>
>>> https://github.com/inukshuk/citeproc-ruby/blob/1c420de0f7a86b7c35782dee86ce62cbebb47ab9/features/condition/is_numeric.feature
>>>
>>> If somebody else helps with the technical infrastructure, I'd be happy
>>> to help reclassifying the existing unit tests.
>>>
>>> Rintze
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> --
> Sebastian Karcher
> Ph.D. Candidate
> Department of Political Science
> Northwestern University
>
--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University
------------------------------------------------------------------------------
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
