Upgrade Storagestrip-periods not working yet?
Strip periods doesn't seem to be working...
I've used the test code below to ensure it's not just one or another style.
...
<citation>
<layout delimiter="; " suffix="." >
<text variable="author" suffix=", " />
<text variable="container-title" form="short" strip-periods="true" />
</layout>
</citation>
<bibliography>
<sort>
<key variable="author" />
</sort>
<layout>
<text macro="author-biblio" suffix=". " />
</layout>
</bibliography>
...
I've used the test code below to ensure it's not just one or another style.
...
<citation>
<layout delimiter="; " suffix="." >
<text variable="author" suffix=", " />
<text variable="container-title" form="short" strip-periods="true" />
</layout>
</citation>
<bibliography>
<sort>
<key variable="author" />
</sort>
<layout>
<text macro="author-biblio" suffix=". " />
</layout>
</bibliography>
...
Not sure where to start. What's your environment, what is the style, and what exact input string is leaving periods in place on you?
(Edit: As a side note, the cs:text node will not produce any output for variable "author", at least in citeproc-js/Zotero 2.1. Name variables must be rendered with cs:names.)
I am using firefox 3.6.12, Zotero 2.0.9, in Windows Vista, if that makes a difference.
<macro name="container-title">
<text strip-periods="true" variable="container-title" form="short" />
</macro>
<macro name="author">
<names variable="author" >
<name strip-periods="true" and="symbol" delimiter-precedes-last="never" />
<substitute>
<text macro="editor" />
</substitute>
</names>
</macro>
<citation et-al-min="4" et-al-use-first="1" >
<layout delimiter="; " suffix="." >
<text macro="author" suffix=" " />
<text macro="container-title" font-style="italic" suffix=" " />
</layout>
</citation>
<bibliography>
<layout>
<text macro="author" suffix=" " />
<text macro="container-title" font-style="italic" suffix=" " />
</layout>
</bibliography>
Zotero 2.0.9 uses CSL 0.8.1, so strip-periods is not available there (and if you validate the style, validation will fail).
Running against some sample input, with bare periods inserted at various locations in the style file, I get this output:
Jane Roe.Journ Title.Jane Roe.Journ Title.... where a period has been stripped from "Journ.", and the other periods are supplied by delimiters or suffix elements.
So the processor looks okay on this; and it's very unlikely that anything in Zotero could change the behavior. If it's not working in your installation, the most likely cause would seem to be invalid CSL, which can have unintended side effects. If you can post a style to gist/github, I'll be happy to give it a try in Zotero to see if the faulty output can be reproduced there.
http://gist.github.com/
(Edit: Just in case, note that the construct <suffix=".">, mentioned in your post above, is not valid, and will either produce an error, or no output at all.)
Here's sample code:
<macro name="container-title">
<text strip-periods="true" variable="container-title" form="short" />
</macro>
<macro name="author">
<names variable="author" >
<name strip-periods="true" and="symbol" name-as-sort-order="first" delimiter-precedes-last="never" />
</names>
</macro>
<citation et-al-min="4" et-al-use-first="1" >
<layout delimiter="; " suffix="." >
<text macro="author" suffix=" " />
<text macro="container-title" font-style="italic" suffix=" " />
</layout>
</citation>
<bibliography>
<layout>
<text macro="author" suffix=" " />
<text macro="container-title" font-style="italic" suffix=" " />
</layout>
</bibliography>
If the authors have periods after their middle initials (or if they have only first initials) this renders as
Levy, Mark A , Oran R Young & Michael Zürn European Journal of International Relations .
If the authors don't have periods after their middle initials, it renders as
Levy, Mark A, Oran R Young & Michael Zürn European Journal of International Relations .
I think that the second is the preferred rendering! Is this fixable?
I can see that it's useful there (to preserve names but drop periods from initials set in the source of the entry). But the CSL specification will need to be amended to allow it.
Right! I see that the test code I gave isn't CSL 1.0 compliant.
The problem is actually with the code in McGill v 7, which does meet the specs for CSL 1.0 (i.e. it doesn't pass strip-periods to <name> directly). I got around that limitation with code which is essentially like the following:
<macro name="container-title">
<text strip-periods="true" variable="container-title" form="short" />
</macro>
<macro name="author">
<text strip-periods="true" macro="author-to-strip" />
</macro>
<macro name="author-to-strip">
<names variable="author" >
<name and="symbol" name-as-sort-order="first" delimiter-precedes-last="never" />
</names>
</macro>
<citation et-al-min="4" et-al-use-first="1" >
<layout delimiter="; " suffix="." >
<text macro="author" suffix=" " />
<text macro="container-title" font-style="italic" suffix=" " />
</layout>
</citation>
<bibliography>
<layout>
<text macro="author" suffix=" " />
<text macro="container-title" font-style="italic" suffix=" " />
</layout>
</bibliography>
It's an ugly work around, but for some reason, unlike with all of the other periods in the string which gets passed back to the "author" macro, the first one in my test citation gets replaced with a space instead of just being deleted. Does that make the error reproduceable?
Seriously, though, it's a little more complicated under the hood than it looks on the surface. Here's a more-or-less full rundown.
The most obvious problem is that, if the processor is extended to wrap content in hyperlinks, a clobber-periods function executed against the rendered string output of the macro (which is really the only feasible way for the processor to handle that construct) would clobber the periods in the URL as well. Ouch.
Even if we assume we'll code around that when it becomes an issue, there is a problem with determining exactly how the periods should be removed. In the general-purpose strip-periods function, we currently preserve space -- and replace the period with a space if it is mid-string. So "Env. L.J." becomes "Env L J". This is where the extraneous space is coming from; the processor is seeing the abbreviation mid-string, so it is forcing in a space. Culling spaces that are followed by punctuation is not practicable when working against rendered string content -- the given-name initial could be followed immediately by a closing tag for small-caps, say, with the space falling after. Parsing around such markup is something that we just don't do.
A cleaner approach would be for us to ban strip-periods on text nodes that call a macro, and allow it on name-part nodes (where it is currently banned). Then you would be legally entitled to do this:
<names variable="author">In fact this will actually work right now, producing the result you're after without any modifications to Zotero or the processor. The only problem is that it won't validate against the CSL 1.0 schema. :(<name>
<name-part name="given" strip-periods="true"/>
</name>
</names>
I'll raise this over in CSL-land and see where the discussion leads us.
Thanks for clearing up the source of these difficulties and why some 'simple' solutions won't work.
Two things: I am not sure that I agree that it makes sense to replace the period with a space. A plain, unrelenting and unforgiving implementation of 'strip periods' function which just stripped them out, no holds barred, would work fine for my purposes. Hein Online, e.g. (as I recall you're a lawyer) gives the abbreviations with the correct amount of white space after the relevant periods, and the most recent McGill guide wouldn't expect a space between the L and J in your example. Nonetheless, I suppose there must be cases where people rely on this way of implementing it; you don't have to prove it to me. Your discussion of URLs suggests to me that programming in exceptions to the 'just get rid of them' rule is only going to get harder.
Finally, You don't have to take the time to explain it to me, but I am not clear on why it would be consistent to ban strip-periods from macros.
Thanks again for all your hard work on both the Zotero and the CSL front. Great to have a voice at the other end when these things come up. I'll have to see about implementing the non-validating code you suggested <wince>.
We could just say that for fine-grained control over the orthography of journal abbreviations (say), we need support for pluggable abbreviation lists.
I'm bundling up some changes for a new processor release. Looking at this strip-periods issue, and after running the tests in a couple of configurations, I've concluded that you're right: strip-periods should do just that, without attempting to insert any sort of placeholder.
When the revised processor comes through in a new release, we'll see whether the change elicits any cries of dismay. If not, we'll be good with Hein Online, and your original coding would, I think, also work.
Has the processor release gone through? The problem still appears with the latest version of the style.
<group delimiter=". ">
<text macro="author-bib" strip-periods="true"/>
<text macro="render-book"/>
</group>
<macro name="author-bib">
<names variable="author">
<name name-as-sort-order="first" and="symbol" sort-separator=", " delimiter-precedes-last="never"/>
<et-al term="et-al"/>
<label form="short" prefix=", "/>
<substitute>
<names variable="editor"/>
</substitute>
</names>
</macro>
When this is passed one or more authors, it works fine. When there are no authors, but only one or more editors, it fails to render the intermediary period. When the strip-periods is removed, the intermediary period returns for both cases (though obviously, with unwanted periods in the authors names left intact).
I've added a test case to the CSL Test Submission group using fbennett's csl feedback plugin which replicates this problem from Zotero 2.1.8, which I am using. I know that certain changes to the processor which impact the implementation of strip-periods will be made in a future release, but I thought that it was important to identify this now, lest it should remain despite those changes.
<group delimiter=". ">
<text macro="author-bib" strip-periods="true"/>
<text macro="render-book"/>
</group>
<macro name="render-book">
<group delimiter=", ">
<text variable="title" font-style="italic" />
<text macro="edition"/>
<text macro="translator"/>
<text macro="editor"/>
</group>
<text macro="publisher-place-year"/>
</macro>
<macro name="author-bib">
<names variable="author">
<name name-as-sort-order="first" and="symbol" sort-separator=", " delimiter-precedes-last="never"/>
<et-al term="et-al"/>
<label form="short" prefix=", "/>
<substitute>
<names variable="editor"/>
</substitute>
</names>
</macro>
Thanks for raising this. I'll take a look in the next couple of days.
(Edit: Simon has picked up the new version and merged it to the 2.1 branch. In the next Zotero release we'll do a better job with the McGill Guide.)
<macro name="author-note">
<names variable="author">
<name and="symbol" delimiter-precedes-last="never"/>
<et-al term="et-al"/>
</names>
</macro>
<citation et-al-min="4" et-al-use-first="1">
<layout delimiter="; " suffix=".">
<text variable="URL" />
<text macro="author-note" strip-periods="true"/>
<text variable="title" quotes="true" suffix=","/>
</layout>
</citation>
<bibliography et-al-min="4" et-al-use-first="1">
<sort>
<key variable="issued"/>
</sort>
<layout>
<text variable="URL" />
</layout>
</bibliography>
</style>
For some reason, this strips periods from the URL and title as well as the author's name. When the call to the author-note macro is removed, the problem disappears. I am using the latest version of Zotero; I've reproduced this problem both in the test pane and the word plugin. I had originally thought that this was limited to the URL variable and had something to do with the "Include URLs..." option but no such luck. It seems to affect all variables. And what is most odd is:
1. It strips periods from the rendering of other variables whether the call to author-note macro comes before or after the rendering of other variables.
2. It appears to strip periods from the rendering of variables in the bibliography, even if the call to author-note is only made in the citation portion of the style!
Thanks for reporting this. It's obviously a true bug.
I've fixed it in the latest processor release (1.0.242). The problem will heal in Zotero when the new version makes its way into a release.