Item type testing in CSL 1.0 and fallbacks
Will Zotero 2.1 continue to support the "fallback" item type testing with the new CSL 1.0 implementation?
This is an old discussion that has not been active in a long time. Instead of commenting here, you should start a new discussion. If you think the content of this discussion is still relevant, you can link to it from your new discussion.
Zotero Item Type >> CSL Type >> CSL Fallback Type
@bdarcus - If you remove the fallbacks, what do you plan to do about the existing styles that will thus get broken?
Also, will the mapping from Zotero Item Type to CSL Type stay as is? I do have a style that requires to distinguish between the Web page type and Blog post and I was hoping that would be possible one day.
Quick sampling through the available styles shows a heavy use of "book", "chapter" and "article" type conditions which may have been knowingly (or unknowingly for that matter) relying on the fallback feature.
My suggestion is:
1/ In CSL 1.0 keep the type processing logic as is in Zotero 2.0
2/ In CSL 1.1 modify csl-types.rnc (this is just a mock-up, hopefully backward-compatible and the part with the native types could be a Zotero-specific extension):
div {
cs-types =
cs-fallback-types
| cs-standard-types
| cs-native-types
}
div {
cs-fallback-types =
"article"
| "book"
| "chapter"
}
div {
cs-standard-types =
"article-journal"
| "article-magazine"
| "article-newspaper"
| "book-type"
| "book-section"
| ...
}
div {
cs-native-types =
"zot-artwork"
| "zot-audio-recording"
| "zot-bill"
| "zot-blog-post"
| "zot-book"
| "zot-book-section"
| ...
}
Some useful links:
Fallback mapping: https://www.zotero.org/trac/browser/extension/trunk/chrome/content/zotero/xpcom/csl.js?rev=5788#L1995
Older thread: http://forums.zotero.org/discussion/8989/resource-type-mapping-is-confusing/
The other problem I mentioned is about exposing the native types. Do I understand correctly from your example above that all Zotero item types, e.g. Computer Program, will be available in CSL? That would be great.
<if type="book motion_picture graphic report bill legal_case song motion_picture" match="any"/>
I expect Zotero won't switch in the new 1.0-compatible processor until the upgraded styles work correctly.
@bdarcus - Even when considering the CSL independence of Zotero...
1/ The fallback feature simplifies the citation style files and makes them easier to develop.
2/ The confusion about the fallback feature may be greatly reduced by using distinct names for types VS fallback types and by making the specification explicit about it.
3/ If a processor implementer cannot comply with the standard, they should simply document the incompatibility. In this particular case, the fallback feature implementation should be straightforward and the Zotero source code is available to everyone, including Mendeley and Pandoc.
4/ The mapping from the native types to CSL types is, too, a kind of a fallback layer.
Considering Zotero...
5/ Zotero is not in the beta stage (cf. Mendeley) and a smooth upgrade path will be crucial.
6/ Inability to access the native types in CSL 0.8 limits the level of compliance with some style guides and so makes the Zotero adoption difficult. Why not include more Zotero native types in the list of the standard CSL types or provide a native-type extension?
I hope there is still some space for a discussion on this toward the CSL 1.0 implementation or CSL 1.1 specification. Maybe the case could be made stronger either way if other style developers could contribute with their opinions.
<macro name="title">
<choose>
<if variable="container-title">
<text variable="title" quotes="true"/>
</if>
<else>
<text variable="title"/>
<else>
</choose>
</macro>
People don't typically believe me when I say this, but It's not generally necessary to use types to condition formatting. My suggestion: contribute towards improving the upgrade XSL stylesheet and help us either a) prove the fallback behavior isn't necessary, or b) show exactly why and how they are. Document this on the xbib list.
And CSL isn't just about Zotero and Mendeley. It's also now seeing development in PHP/Drupal, and has an implementation in Haskell (for use in part with the excellent pandoc tool); not to mention that I have a python version I periodically work on.
@bdarcus: what is the current selection of CSL item types based on? The Bibliographic Ontology? (http://bibliontology.com/)
@erazlogo on the XSLT stylesheet: could you give specifics? I thought I had most things covered. You might want to post your comments to the xbiblio mailing list.
In any case, I stand by the point that fallbacks are unnecessary; that the same logic can be easily represented using the conditional structure (and without having to include an exhaustive list of types there).
Also: So rather than just note this, can you suggest improvements? I wrote the stylesheet awhile back, and I simply didn't consider this case. Might be hard to program, but maybe not.
<macro name="title-note">
In CSL 1.0 the macro, using your example above and without the exhaustive list of types, will look like this:<choose>
<if variable="title" match="none">
<text variable="genre"/>
</if>
<else-if type="book">
<text variable="title" font-style="italic"/>
</else-if>
<else>
<text variable="title" quotes="true"/>
</else>
</choose>
</macro>
<macro name="title-note">
An automatically converted macro with an exhaustive list of types will look like this:<choose>
<if variable="title" match="none">
<text variable="genre"/>
</if>
<else-if variable="container-title">
<text variable="title" quotes="true"/>
</else-if>
<else-if type="manuscript thesis speech patent map">
<text variable="title" quotes="true"/>
</else-if>
<else>
<text variable="title" font-style="italic"/>
</else>
</choose>
</macro>
<macro name="title-note">
<choose>
<if variable="title" match="none">
<text variable="genre"/>
</if>
<else-if type="book graphic song bill legal_case motion_picture report">
<text variable="title" font-style="italic"/>
</else-if>
<else>
<text variable="title" quotes="true"/>
</else>
</choose>
</macro>
So, we can do without fallbacks, sure; but not without types. As you can see, the macro with the "exhaustive list of types" is actually simpler than the one without. Ok, I will look over and will start a new thread and post on the xbiblio list.
Now, for the role of types, it would be great if the styles could do without types entirely, but they cannot. I believe erazlogo's responses covered that well. On top of that I would like to re-iterate my point: The point is about the other end of the mapping spectrum. In most cases, CSL style developers do not have a means to influence established style guides. My previous example of the requirement to distinguish between a web page (title in italics) and blog post (title in quotes) is a use case that is not supported at the moment. Is CSL going to be extended to include more native types?
Also, while preparing the fallback-behavior overview I mentioned above (http://docs.google.com/View?id=dg6h9k72_64hzmsmqgb), I noticed that there is a conflict that should be resolved if fallback behavior is going to be defined on a CSL-only level (without knowledge of the Zotero>CSL mapping): Zotero's "podcast" and "audioRecording" types are both mapped to "song", but "podcast" falls back to "article", whereas "audioRecording" falls back to "book".
Zotero type Document >> No CSL type >> Fallback type article
Another thought - Why don't we replace all CSL types with just the three fallback types and have some schema extension mechanism to support all native types? The current set of types is mapped from the Zotero native types arbitrarily anyway. Since no mapping guidelines are defined in the standard, various compliant processors may still produce incompatible output. It should be quite straightforward to define the mapping guidelines in the standard for a small set of fallback types. Moreover, this would be an incentive for CSL style developers to reduce the use of types as much as they can to make their CSL styles tool-independent. The upgrade would still require to migrate hundreds of styles though (unless you start with the native types identical to the current CSL types).
I described this in this document.
Keep in mind, too, that when I created this, there was no cs:choose element. Instead, there were separate template for each type, and the schema required templates for each of the fallback types. Zotero designed their list independently of the one I designed for CSL, and I don't agree with all their decisions. Extensions seems to me like a really bad idea, since it will encourage forking. Ideally, at some point, all CSL implementors come up with some ground rules on types and how they get extended, but I've been asking for this for literally years, and it's yet to see happen.
On the other hand, a better approach may still be to keep the current CSL types and explicate their strong ontology in the standard (not just a controlled vocabulary of types).
Am not entirely rejecting your argument here; I just think we have a few different balls in the air, and there may be other ways to ultimately address these issues (the most immediate being how to reliably update existing styles to 1.0). To be concrete, my short-to-long-term gaols are twofold: first, to improve the update XSL so conversion is fully automatic, and second, to make sure the online CSL wizard the Mendeley guys are working on is as good as it can be (so users don't have to worry about CSL syntax ;-)).
As I mentioned earlier, if we can document that the removal of the "class" types and fallbacks makes the first goal unattainable, then we can talk about adding it back in 1.1.