FYI, with help from Frank and Rintze, we merged the split branch to
trunk, and tagged 1.0RC1.Please take look, and test the validation
with existing styles updated using the update.xsl.
Bruce
So I created a simple bash script that runs the update.xsl script on
the directory of csl files in the zotero repo, and then validates them
against the RC1 schema.
There a few errors on the schema (and another one or two on the xslt):
1.0/yeast.csl:120:4: error: element
http://purl.org/net/xbiblio/csl^item not allowed
required:
element http://purl.org/net/xbiblio/csl^layout
1.0/yeast.csl:185:2: error: unfinished content of element
http://purl.org/net/xbiblio/csl^bibliography
required:
element http://purl.org/net/xbiblio/csl^layout
So I’m now forgetting a) why I didn’t change cs:layout to cs:item (I
thought I did), and b) why I was doing that anyway (had to do with
Frank’s desire for consistency between cite and bib).
Any insight?
Bruce
Another issue:
What should I do with “include-periods” attributes in the upgrade? Strip them?
And what, then, to do about the rest? Is there any particular reliable
logic we can use to add “strip-periods”?
Bruce
Dates:
I haven’t really followed the latest date changes, so I have no idea
how to write the XSL code to handle it. Rintze, if you have any
feedback, please post (or if you want to experiment with the xslt,
feel free).
Bruce
FYI, with help from Frank and Rintze, we merged the split branch to
trunk, and tagged 1.0RC1.Please take look, and test the validation
with existing styles updated using the update.xsl.So I created a simple bash script that runs the update.xsl script on
the directory of csl files in the zotero repo, and then validates them
against the RC1 schema.There a few errors on the schema (and another one or two on the xslt):
1.0/yeast.csl:120:4: error: element
http://purl.org/net/xbiblio/csl^item not allowed
required:
element http://purl.org/net/xbiblio/csl^layout
1.0/yeast.csl:185:2: error: unfinished content of element
http://purl.org/net/xbiblio/csl^bibliography
required:
element http://purl.org/net/xbiblio/csl^layoutSo I’m now forgetting a) why I didn’t change cs:layout to cs:item (I
thought I did), and b) why I was doing that anyway (had to do with
Frank’s desire for consistency between cite and bib).
Short answer: You can leave layout as it stands.
Longer answer:
There is a difference between the role of delimiters and affixes on
citation/layout and on bibliography/layout. The citation/layout
affixes are applied once, to the front and back of a citation (that
may be composed of multiple cites). The bibliography/layout affixes
are applied repeatedly, to every entry in the bibliography. This
difference in behaviour was undocumented, and I asked that either the
two be brought into alignment, or that the difference be documented.
Bringing the two into alignment would require significant change to
the CSL of about 60 styles, if I remember right. Any style with
affixes or delimiters on the bibliography/layout element (in CSL 0.8
terms) would need to have the nodes inside the layout wrapped in a
group, with the affixes and delimiter moved down to the group node.
My argument in favor of doing this was that this would free up the
bibliography node for affixes applied once to the bibliography as a
whole. That, and a taste for symmetry. However, now, looking back
after citeproc-js is finished, I can’t see any real-world need for
affixes on the bibliography, or for changing the joins between its
elements. So it’s probably not worth the risk, effort, and hassle of
making the change.
In the last list discussion we had on this one, you proposed that the
citation and bibliography nodes effectively take over the roles of
their respective layout nodes, to bring the roles of the two into
alignment, and to rename layout as “item”, to make it clear that its
affixes applied to individual entries.
Your example code did not contain a “sort” element, and I asked where
that should go. You suggested two options:
- as it is now; a child of the context element, and sibling of cs:item.
- along with 1, add a cs:list parent for cs:item
I don’t think we reached a final decision.
It’s really only about symmetry, as far as I can see now. If you want
to avoid being overwhelmed with changes, this can be left as in 0.8,
with no change to layout and a small note in the specification about
the difference in behavior. I solemnly promise not to complain.
Frank
Dates:
I haven’t really followed the latest date changes, so I have no idea
how to write the XSL code to handle it. Rintze, if you have any
feedback, please post (or if you want to experiment with the xslt,
feel free).
I think you can leave dates untouched. Both the new schema and
citeproc-js are backward compatible with the old date format.
Localized dates require some changes, but these can be applied by hand
to the small number of core styles that need to be fully localizable.
Frank
Another issue:
What should I do with “include-periods” attributes in the upgrade? Strip them?
And what, then, to do about the rest? Is there any particular reliable
logic we can use to add “strip-periods”?
A straight inverse of include-periods should do the trick, if that’s
possible. Both label nodes, and text nodes with a term attribute
should get strip-periods=“true” if they had no include-periods=“true”
attribute; and include-periods is just dropped where it occurs.
Rintze should have a look at that thought, though.
We’re working under the assumption that all the abbreviations in the locale
files will be rewritten to use periods (when applicable), right?
Looking at the English locale (
https://xbiblio.svn.sourceforge.net/svnroot/xbiblio/csl/locales/locales-en-US.xml),
the full inversion proposed by Frank would be problematic for the "no date"
term (“n.d.”). I’m not sure about the “sub verbo”-terms (are those only used
in labels for locators?). And there might be additional affected terms
because of the other locales. So perhaps we should restrict the inversion to
labels?
Also, I had a look at APA, and it uses suffixes to apply periods to the
volume-term:
This will result in double periods once the locale terms are rewritten
(except when, of course, we use the full inversion and apply
’strip-periods=“true”’). (also, what is exactly the reason for not using
’cs:label’ for the volume-term? The schema doesn’t allow for that, right?)
RintzeOn Wed, Aug 19, 2009 at 1:45 AM, Frank Bennett <@Frank_Bennett>wrote:
Yes. We can ask folks on BabelZilla to review the abbreviations once we
put up a build of Zotero with the latest locale files.
Will you convert the locale files to the new format before uploading them to
Babelzilla (I guess that requires another upgrade.xls)? I’m thinking it
might be just as efficient to do the date/option-localization myself. The
former is tricky to explain to people unfamiliar with CSL (especially
regarding the correct use of affixes), and the latter seems a small task
(Wikipedia suggests that en-US is the only locale for which
punctuation-in-quotes should be set to true,
http://en.wikipedia.org/wiki/American_and_British_English_differences#Punctuation).
It might also be useful to include some XML comments in the locale files to
give the translators some instructions.
Rintze