Upgrade StorageBug with CSL match="none" handling?
Hi there,
I'm developing a new CSL style for my thesis, and I've noticed a bit of a bug. I'm not sure if it's a Zotero error or a CSL one, but I thought I'd start with this list.
I've written a macro to for formatting volume numbers for journal articles and legal cases. Basically, if there is no volume number then the year should be put in [ ] otherwise, it should be the year in ( ) followed by the volume number. Some examples:
Cain v Universal Pictures Co (1942) 47 F.Supp 1013
Stephen Rebikoff, "Restructuring the Test For Copyright Infringement In Relation to Literary And Dramatic Plots," [2001] MULR 12
This is the macro:
<macro name="volume-macro">
<choose>
<if type="article legal_case" match="any">
<choose>
<if variable="volume" match="none">
<date variable="issued">
<date-part name="year" prefix=" [" suffix="]"/>
</date>
</if>
<else>
<date variable="issued">
<date-part name="year" prefix=" (" suffix=")"/>
</date>
<text variable="volume" prefix=" "/>
</else>
</choose>
</if>
<else>
<group prefix=" (" suffix=")" delimiter=" ">
<text variable="edition"/>
<text macro="editor-translator"/>
<text macro="publisher"/>
<date variable="issued">
<date-part name="year"/>
</date>
</group>
</else>
</choose>
</macro>
The problem I'm having is that *sometimes* even when there is a volume number present, I'm seeing the year only in square brackets. I've worked out that if I delete the field in Zotero, then re-add it, it formats correctly.
Just to prove the point, I added a <text variable="volume"/> under the match="none" statement, and get the following results in the Zotero test pane:
Cain v Universal Pictures Co (1942) 47 F.Supp 1013 at 3.
Financial Control Associates v Equity Builders [1992] 799 F Supp 1103 at 3.
Sid & Marty Kroft Television Productions v McDonald's Production (1977) 562 F.2d 1157 at 3.
Herbert Rosenthal Jewelry Corp v Kalpakian [1971] 446 F.2d 742 at 3.
So clearly the matching is sometimes ignoring the contents of the volume field and other times picking it up. Where should I go from here?
I'm developing a new CSL style for my thesis, and I've noticed a bit of a bug. I'm not sure if it's a Zotero error or a CSL one, but I thought I'd start with this list.
I've written a macro to for formatting volume numbers for journal articles and legal cases. Basically, if there is no volume number then the year should be put in [ ] otherwise, it should be the year in ( ) followed by the volume number. Some examples:
Cain v Universal Pictures Co (1942) 47 F.Supp 1013
Stephen Rebikoff, "Restructuring the Test For Copyright Infringement In Relation to Literary And Dramatic Plots," [2001] MULR 12
This is the macro:
<macro name="volume-macro">
<choose>
<if type="article legal_case" match="any">
<choose>
<if variable="volume" match="none">
<date variable="issued">
<date-part name="year" prefix=" [" suffix="]"/>
</date>
</if>
<else>
<date variable="issued">
<date-part name="year" prefix=" (" suffix=")"/>
</date>
<text variable="volume" prefix=" "/>
</else>
</choose>
</if>
<else>
<group prefix=" (" suffix=")" delimiter=" ">
<text variable="edition"/>
<text macro="editor-translator"/>
<text macro="publisher"/>
<date variable="issued">
<date-part name="year"/>
</date>
</group>
</else>
</choose>
</macro>
The problem I'm having is that *sometimes* even when there is a volume number present, I'm seeing the year only in square brackets. I've worked out that if I delete the field in Zotero, then re-add it, it formats correctly.
Just to prove the point, I added a <text variable="volume"/> under the match="none" statement, and get the following results in the Zotero test pane:
Cain v Universal Pictures Co (1942) 47 F.Supp 1013 at 3.
Financial Control Associates v Equity Builders [1992] 799 F Supp 1103 at 3.
Sid & Marty Kroft Television Productions v McDonald's Production (1977) 562 F.2d 1157 at 3.
Herbert Rosenthal Jewelry Corp v Kalpakian [1971] 446 F.2d 742 at 3.
So clearly the matching is sometimes ignoring the contents of the volume field and other times picking it up. Where should I go from here?
-
dstillmanFixed in latest 1.0 and 1.5 dev builds. (Values stored as integers in the DB weren't matched properly.) Thanks.