Hello,
I want to make difference between ibid. and Ibid. in a style? How can I
test if there is a prefix? Because if it is, i want to have ibid.; if it
isn’t, i want Ibid. (the firs word in sentence).
Thank you,
Nicolae Turcan
I’m not following. Can you explain again?
Bruce
Bruce D’Arcus a scris:
Hello,
I want to make difference between ibid. and Ibid. in a style? How can I
test if there is a prefix? Because if it is, i want to have ibid.; if it
isn’t, i want Ibid. (the firs word in sentence).I’m not following. Can you explain again?
Bruce
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
Best Open Source Mac Front-Ends 2023
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
xbiblio-devel List Signup and Options
Hi,
There is an example for notes. See the difference between Ibid. (with
capital I) and ibid. (with i), if there is a prefix.
- Nicolae Turcan, /Philosophy of Cioran/, Limes, Cluj, 2008, pp. 5-27.
- /Ibid/., p. 33.
- See also this idea in /ibid/., pp. 50-55.
How can I test if there are words in prefix field? Can we have
ibid-with-prefix for non capitalize first letter of word ibid.?
My style always make capital-first Ibid:
Thank you,
Nicolae Turcan
Well, I’m not sure this the best way. Don’t we want to simply treat
note as a sentence, so that the ibid is capitalized since it begins
it? Put differently, can you imagine a case where your “2” note would
not be capitalized?
Bruce
Bruce D’Arcus a scris:> On Thu, Feb 26, 2009 at 12:53 PM, nicturcan <@nicturcan> wrote:
There is an example for notes. See the difference between Ibid. (with
capital I) and ibid. (with i), if there is a prefix.
- Nicolae Turcan, /Philosophy of Cioran/, Limes, Cluj, 2008, pp. 5-27.
- /Ibid/., p. 33.
- See also this idea in /ibid/., pp. 50-55.
How can I test if there are words in prefix field? Can we have
ibid-with-prefix for non capitalize first letter of word ibid.?
My style always make capital-first Ibid:Well, I’m not sure this the best way. Don’t we want to simply treat
note as a sentence, so that the ibid is capitalized since it begins
it? Put differently, can you imagine a case where your “2” note would
not be capitalized?Bruce
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
Best Open Source Mac Front-Ends 2023
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
xbiblio-devel List Signup and Options
No, the note 2 is always Ibid. (capitalized), because is the first word
in a sentence. But how can I code that?
Nicolae
Bruce D’Arcus a scris:> On Thu, Feb 26, 2009 at 12:53 PM, nicturcan <@nicturcan> wrote:
There is an example for notes. See the difference between Ibid. (with
capital I) and ibid. (with i), if there is a prefix.
- Nicolae Turcan, /Philosophy of Cioran/, Limes, Cluj, 2008, pp. 5-27.
- /Ibid/., p. 33.
- See also this idea in /ibid/., pp. 50-55.
How can I test if there are words in prefix field? Can we have
ibid-with-prefix for non capitalize first letter of word ibid.?
My style always make capital-first Ibid:Well, I’m not sure this the best way. Don’t we want to simply treat
note as a sentence, so that the ibid is capitalized since it begins
it? Put differently, can you imagine a case where your “2” note would
not be capitalized?Bruce
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
xbiblio-devel List Signup and Options
I’ve tried with text-case=“sentence” but doesn’t work…
Nicolae
Bruce D’Arcus a scris:
There is an example for notes. See the difference between Ibid. (with
capital I) and ibid. (with i), if there is a prefix.
- Nicolae Turcan, /Philosophy of Cioran/, Limes, Cluj, 2008, pp. 5-27.
- /Ibid/., p. 33.
- See also this idea in /ibid/., pp. 50-55.
How can I test if there are words in prefix field? Can we have
ibid-with-prefix for non capitalize first letter of word ibid.?
My style always make capital-first Ibid:Well, I’m not sure this the best way. Don’t we want to simply treat
note as a sentence, so that the ibid is capitalized since it begins
it? Put differently, can you imagine a case where your “2” note would
not be capitalized?Bruce
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
Best Open Source Mac Front-Ends 2023
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
xbiblio-devel List Signup and OptionsI’ve tried with text-case=“sentence” but doesn’t work…
This an important use case for note styles. CSL can’t handle it at
the moment, and I agree with Nicolae that it should be covered. In a
style that handles it, any text prefix added by the user through the
GUI that does not end in terminal punctuation (“.”, “:” or “;”) should
trigger lower-casing of Ibid.
I implemented this behaviour in our local version of Zotero a month
ago, but it required arcane changes to the citation formatter that
really shouldn’t go into the mainstream release. It will be much
easier to handle in the new citeproc-js CSL formatter that I am
building at the moment. Whether it gets included in the final release
depends on adoption in xbiblio/CSL.
To cover other languages with other terminal punctuation marks would
require a header option in the citation, such as .
Is there agreement on this addition?
Frank
Bruce D’Arcus a scris:
There is an example for notes. See the difference between Ibid. (with
capital I) and ibid. (with i), if there is a prefix.
- Nicolae Turcan, /Philosophy of Cioran/, Limes, Cluj, 2008, pp. 5-27.
- /Ibid/., p. 33.
- See also this idea in /ibid/., pp. 50-55.
How can I test if there are words in prefix field? Can we have
ibid-with-prefix for non capitalize first letter of word ibid.?
My style always make capital-first Ibid:Well, I’m not sure this the best way. Don’t we want to simply treat
note as a sentence, so that the ibid is capitalized since it begins
it? Put differently, can you imagine a case where your “2” note would
not be capitalized?Bruce
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
Best Open Source Mac Front-Ends 2023
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
xbiblio-devel List Signup and OptionsI’ve tried with text-case=“sentence” but doesn’t work…
This an important use case for note styles. CSL can’t handle it at
the moment, and I agree with Nicolae that it should be covered. In a
style that handles it, any text prefix added by the user through the
GUI that does not end in terminal punctuation (“.”, “:” or “;”) should
trigger lower-casing of Ibid.I implemented this behaviour in our local version of Zotero a month
ago, but it required arcane changes to the citation formatter that
really shouldn’t go into the mainstream release. It will be much
easier to handle in the new citeproc-js CSL formatter that I am
building at the moment. Whether it gets included in the final release
depends on adoption in xbiblio/CSL.To cover other languages with other terminal punctuation marks would
require a header option in the citation, such as .Is there agreement on this addition?
Sorry, I should have taken more thorough.
The text-case=“sentence” attribute can’t handle this case, because
changes to the case of characters in the content string need to be
applied before font decorations. That limits the scope of the
case-change to the content string itself; it can’t take the
prefix/suffix into account, because the string has been formatted at
the point those strings are tacked on. This isn’t a problem in the
implementation, it’s just the order in which these operations have to
be performed.
The header option would be needed to make prefix-punctuation
sensitivity work against all languages, but you would also need a
condition. In our local CSL, I use something like this:
The companion header option would be something like:
How does that sound?
Frank
The text-case=“sentence” attribute can’t handle this case, because
changes to the case of characters in the content string need to be
applied before font decorations.
Hang on. You’re talking implementation details; why should this
necessarily have any particular bearing on CSL syntax?
That limits the scope of the case-change to the content string itself; it can’t take the
prefix/suffix into account, because the string has been formatted at
the point those strings are tacked on. This isn’t a problem in the
implementation, it’s just the order in which these operations have to
be performed.The header option would be needed to make prefix-punctuation
sensitivity work against all languages, but you would also need a
condition. In our local CSL, I use something like this:The companion header option would be something like:
How does that sound?
I don’t know:
a) what it means
b) why it’s needed
For example, we already have Zotero stripping duplicate punctuation (I
don’t believe Andrea has implemented this yet), without explicit
encoding of how to do that in the style. I prefer that approach. Why
can’t it work for this case?
E.g. so if the rule for punctuation is in part “strip duplicate
commas,” then the rule here is “note citation content may effectively
be a complete setnence; processor should treat strings accordingly.”
The issue doesn’t normally come up because most strings that start a
citation (authors, title, a year perhaps) are already capitalized.
Bruce
The text-case=“sentence” attribute can’t handle this case, because
changes to the case of characters in the content string need to be
applied before font decorations.Hang on. You’re talking implementation details; why should this
necessarily have any particular bearing on CSL syntax?
Because it’s better for everyone if the CSL syntax specification is
not a nightmare to implement. We can talk further about this, but
slurping prefix, content and suffix up into a text-case declaration,
or applying text-case to a group, is one of those things that isn’t
going to happen.
That limits the scope of the case-change to the content string itself; it can’t take the
prefix/suffix into account, because the string has been formatted at
the point those strings are tacked on. This isn’t a problem in the
implementation, it’s just the order in which these operations have to
be performed.The header option would be needed to make prefix-punctuation
sensitivity work against all languages, but you would also need a
condition. In our local CSL, I use something like this:The companion header option would be something like:
How does that sound?
I don’t know:
a) what it means
b) why it’s needed
This is a real issue that two of us have run up against. I have
proposed a working solution that would address Nicolae’s use case and
the needs of the style I’m building. We’ve come to the list because
we need to have this fixed. If there is not an existing means of
addressing this that we have missed, there is no call to be
dismissive.
For example, we already have Zotero stripping duplicate punctuation (I
don’t believe Andrea has implemented this yet), without explicit
encoding of how to do that in the style. I prefer that approach. Why
can’t it work for this case?
Stripping duplicate commas affects only one field, and it is a fix
that can be applied to all prefixes without hurting anything. But in
this case, whether to touch the case of a field depends on its
syntactic role. CSL can discriminate between one term and another.
Zotero, or citeproc-hs, cannot (or at least they can’t do so without
hard-coding in assumptions that add complexity and will eventually
break things unexpectedly, which would be a stupid design decision).
I don’t want to touch a string with lowercase for some terms. For
others I do. CSL can tell which is which, so that’s where the change
is needed.
E.g. so if the rule for punctuation is in part “strip duplicate
commas,” then the rule here is “note citation content may effectively
be a complete setnence; processor should treat strings accordingly.”
For the reasons stated above, this won’t work.
The issue doesn’t normally come up because most strings that start a
citation (authors, title, a year perhaps) are already capitalized.
Yes, but when it does come up, it needs to be handled correctly.
I agree with Bruce–I think this is a general rule that is easier to
implement across the board in citeproc or Zotero instead of coding in
CSS. Could we just automatically uppercase any first letter in the
beginning of a sentence, and just set ibid to “lowercase”?
Elena
The text-case=“sentence” attribute can’t handle this case, because
changes to the case of characters in the content string need to be
applied before font decorations.Hang on. You’re talking implementation details; why should this
necessarily have any particular bearing on CSL syntax?Because it’s better for everyone if the CSL syntax specification is
not a nightmare to implement.
“Nightmare” for whom? E.g. if I make a change that makes it
marginally easier for you or another programmer to implement CSL, but
which makes it harder for style authors to author CSL styles, is that
really in our collective long-term benefit?
But I also think we have different understandings of the problem we
need to solve, so we need to talk this through.
We can talk further about this, but
slurping prefix, content and suffix up into a text-case declaration,
or applying text-case to a group, is one of those things that isn’t
going to happen.
Per Elena’s suggestion, I’m just not seeing how this is a problem. Why
can’t you just look at the first character of the finished output and
confirm it’s upper case? If if’s not, then uppercase it (in note
styles).
This seems to work for cases where there’s an empty “ibid” (the case
here) but also for cases where you have an author-date reference like
(see Doe, 1999), where the “see” would also get uppercase under a note
style.
That limits the scope of the case-change to the content string itself; it can’t take the
prefix/suffix into account, because the string has been formatted at
the point those strings are tacked on. This isn’t a problem in the
implementation, it’s just the order in which these operations have to
be performed.The header option would be needed to make prefix-punctuation
sensitivity work against all languages, but you would also need a
condition. In our local CSL, I use something like this:The companion header option would be something like:
How does that sound?
I don’t know:
a) what it means
b) why it’s needed
This is a real issue that two of us have run up against. I have
proposed a working solution that would address Nicolae’s use case and
the needs of the style I’m building. We’ve come to the list because
we need to have this fixed. If there is not an existing means of
addressing this that we have missed, there is no call to be
dismissive.
I don’t mean to sound dismissive, and I certainly do see the output
problem Nicolae points to and agree it needs to be solved. I’m just
trying to understand where to place the solution. To me, it’s not in
the CSL syntax.
For example, we already have Zotero stripping duplicate punctuation (I
don’t believe Andrea has implemented this yet), without explicit
encoding of how to do that in the style. I prefer that approach. Why
can’t it work for this case?Stripping duplicate commas affects only one field, and it is a fix
that can be applied to all prefixes without hurting anything.
Right.
But in this case, whether to touch the case of a field depends on its
syntactic role.
Not if you are only concerned with the very first character of the
citation group. Is there a reason you’d have to be concerned with
more?
…
Bruce
The text-case=“sentence” attribute can’t handle this case, because
changes to the case of characters in the content string need to be
applied before font decorations.Hang on. You’re talking implementation details; why should this
necessarily have any particular bearing on CSL syntax?Because it’s better for everyone if the CSL syntax specification is
not a nightmare to implement.“Nightmare” for whom? E.g. if I make a change that makes it
marginally easier for you or another programmer to implement CSL, but
which makes it harder for style authors to author CSL styles, is that
really in our collective long-term benefit?But I also think we have different understandings of the problem we
need to solve, so we need to talk this through.We can talk further about this, but
slurping prefix, content and suffix up into a text-case declaration,
or applying text-case to a group, is one of those things that isn’t
going to happen.Per Elena’s suggestion, I’m just not seeing how this is a problem. Why
can’t you just look at the first character of the finished output and
confirm it’s upper case? If if’s not, then uppercase it (in note
styles).This seems to work for cases where there’s an empty “ibid” (the case
here) but also for cases where you have an author-date reference like
(see Doe, 1999), where the “see” would also get uppercase under a note
style.
The processing is nested. In the first stage, tokens in the deepest
CSL groups are composed into strings, and their formatting tags and
string decorations are added. These formatted strings are composed in
turn at the next level, and so on until the citation is complete.
Because there may be conditional branching at each grouping level, we
cannot know what is in the string, and what its first element will be,
until this first phase is complete. In stage two, the (Zotero user)
prefix and suffix are appended. In stage three, these sentence units
are composed into a citation group.
So at the start of processing, we do know whether there is a (Zotero
user) prefix and suffix for each cite, but we don’t know which element
needs to have its first letter capitalized.
So the earliest point at which we can look for the “first character”
is in the second phase, after the core citation has emerged from the
formatter. Unfortunately, at that point, the first character in the
cite is no longer the first character in the string; it has formatting
tags around it (the example I gave from the Bluebook is italicized).
So to reach it, you would need to step over the formatting tags, and
these might be in HTML or RTF, in some binary format, or in some kind
of plain text markup. It’s not practicable.
When I ran into this problem, I looked hard at ways of handling it
without touching CSL, but I came up dry. Where there is a need to
capitalize the first letter in a cite, you need to get at the string
before it heads into the formatter, and the only way to do that is
through a CSL declaration of some sort. I think Andrea would tell you
the same thing.
Frank
The processing is nested. In the first stage, tokens in the deepest
CSL groups are composed into strings, and their formatting tags and
string decorations are added. These formatted strings are composed in
turn at the next level, and so on until the citation is complete.
Because there may be conditional branching at each grouping level, we
cannot know what is in the string, and what its first element will be,
until this first phase is complete. In stage two, the (Zotero user)
prefix and suffix are appended. In stage three, these sentence units
are composed into a citation group.So at the start of processing, we do know whether there is a (Zotero
user) prefix and suffix for each cite, but we don’t know which element
needs to have its first letter capitalized.So the earliest point at which we can look for the “first character”
is in the second phase, after the core citation has emerged from the
formatter. Unfortunately, at that point, the first character in the
cite is no longer the first character in the string; it has formatting
tags around it (the example I gave from the Bluebook is italicized).
So to reach it, you would need to step over the formatting tags, and
these might be in HTML or RTF, in some binary format, or in some kind
of plain text markup. It’s not practicable.
OK, but you’re still talking about specific implementation details
(tags and such). Do we agree with the basic premise that I’ve
suggested, however?
When I think about implementation, and a final output stage, I think
about a list of formatted strings. In an OO language like Python or
Ruby (or JS), I expect those are likely objects, so that one can
imagine a list of those objects, where you can take the first item in
the list, and look at its content. E.g. I expect in an intermediate
representation, you can still look at the content; e.g.:
print(formatted_reference_list[0].content)
What am I missing?
When I ran into this problem, I looked hard at ways of handling it
without touching CSL, but I came up dry. Where there is a need to
capitalize the first letter in a cite, you need to get at the string
before it heads into the formatter, and the only way to do that is
through a CSL declaration of some sort. I think Andrea would tell you
the same thing.
Andrea: thoughts?
Bruce
The processing is nested. In the first stage, tokens in the deepest
CSL groups are composed into strings, and their formatting tags and
string decorations are added. These formatted strings are composed in
turn at the next level, and so on until the citation is complete.
Because there may be conditional branching at each grouping level, we
cannot know what is in the string, and what its first element will be,
until this first phase is complete. In stage two, the (Zotero user)
prefix and suffix are appended. In stage three, these sentence units
are composed into a citation group.So at the start of processing, we do know whether there is a (Zotero
user) prefix and suffix for each cite, but we don’t know which element
needs to have its first letter capitalized.So the earliest point at which we can look for the “first character”
is in the second phase, after the core citation has emerged from the
formatter. Unfortunately, at that point, the first character in the
cite is no longer the first character in the string; it has formatting
tags around it (the example I gave from the Bluebook is italicized).
So to reach it, you would need to step over the formatting tags, and
these might be in HTML or RTF, in some binary format, or in some kind
of plain text markup. It’s not practicable.OK, but you’re still talking about specific implementation details
(tags and such). Do we agree with the basic premise that I’ve
suggested, however?When I think about implementation, and a final output stage, I think
about a list of formatted strings. In an OO language like Python or
Ruby (or JS), I expect those are likely objects, so that one can
imagine a list of those objects, where you can take the first item in
the list, and look at its content. E.g. I expect in an intermediate
representation, you can still look at the content; e.g.:print(formatted_reference_list[0].content)What am I missing?
You’re either going to get a group token with that zero index, or the
entire object, depending on how the internal representation is set up.
Still, that improves things slightly by preserving the content in
token form into the final stage of processing. It means extra
overhead, though, because to separate conditional branching from final
rendering, you’ll need to introduce a fourth pass over the tokens. In
the fourth phase, as I say you would still have to determine where the
content starts, because in OO form all of the grouping tags are still
going to be there (in XML, you could grab the text content of the full
object in one go to get the first character – but then there went the
formatting).
In the case of citeproc-js, the internal form is a flat token list,
which means it’s relatively simple (that is, it would be, after
someone got done deleting the output machinery I’ve built, introduced
the fourth layer of processing, and added the stuff to look for the
first character string embedded in an object in the token list). An
implementation that mirrors the nested structures of XML in the
citation before rendering would require a depth-first walk of the tree
structure in search of the target object, which will be more costly.
In both cases it can be automated, but the overhead adds up, and the
extra operations this contemplates would need to be performed on every
citation rendered, whether it’s necessary in the end or not. The CSL
conditional would be faster, since only the affected object would be
touched, and it would be skipped over except when it was needed. It’s
simple and clean.
Frank
The processing is nested. In the first stage, tokens in the deepest
CSL groups are composed into strings, and their formatting tags and
string decorations are added. These formatted strings are composed in
turn at the next level, and so on until the citation is complete.
Because there may be conditional branching at each grouping level, we
cannot know what is in the string, and what its first element will be,
until this first phase is complete. In stage two, the (Zotero user)
prefix and suffix are appended. In stage three, these sentence units
are composed into a citation group.So at the start of processing, we do know whether there is a (Zotero
user) prefix and suffix for each cite, but we don’t know which element
needs to have its first letter capitalized.So the earliest point at which we can look for the “first character”
is in the second phase, after the core citation has emerged from the
formatter. Unfortunately, at that point, the first character in the
cite is no longer the first character in the string; it has formatting
tags around it (the example I gave from the Bluebook is italicized).
So to reach it, you would need to step over the formatting tags, and
these might be in HTML or RTF, in some binary format, or in some kind
of plain text markup. It’s not practicable.OK, but you’re still talking about specific implementation details
(tags and such). Do we agree with the basic premise that I’ve
suggested, however?When I think about implementation, and a final output stage, I think
about a list of formatted strings. In an OO language like Python or
Ruby (or JS), I expect those are likely objects, so that one can
imagine a list of those objects, where you can take the first item in
the list, and look at its content. E.g. I expect in an intermediate
representation, you can still look at the content; e.g.:print(formatted_reference_list[0].content)What am I missing?
You’re either going to get a group token with that zero index, or the
entire object, depending on how the internal representation is set up.Still, that improves things slightly by preserving the content in
token form into the final stage of processing. It means extra
overhead, though, because to separate conditional branching from final
rendering, you’ll need to introduce a fourth pass over the tokens. In
the fourth phase, as I say you would still have to determine where the
content starts, because in OO form all of the grouping tags are still
going to be there (in XML, you could grab the text content of the full
object in one go to get the first character – but then there went the
formatting).In the case of citeproc-js, the internal form is a flat token list,
which means it’s relatively simple (that is, it would be, after
someone got done deleting the output machinery I’ve built, introduced
the fourth layer of processing, and added the stuff to look for the
first character string embedded in an object in the token list). An
implementation that mirrors the nested structures of XML in the
citation before rendering would require a depth-first walk of the tree
structure in search of the target object, which will be more costly.
In both cases it can be automated, but the overhead adds up, and the
extra operations this contemplates would need to be performed on every
citation rendered, whether it’s necessary in the end or not. The CSL
conditional would be faster, since only the affected object would be
touched, and it would be skipped over except when it was needed. It’s
simple and clean.
I think I may have an idea how this can be done outside of CSL. Give
me a couple of weeks, we’ll see how it goes.
I feel a bit sorry because I’m not able, at the present time, to
closely follow your discussions (I have a 2 month daughter to whom
I’m dedicating much of my attention).
As far as I understand it I believe that Frank is right.
You need to have some context information in order to decide whether
the first letter of a cite must be capitalized or not. The Haskell
citeproc, at the present time, only receives a list of tuples (made of
the citation and its locator). This is possible because the text-case
attribute is not flexible and context dependent. So, I see 2 ways of
having a flexible and context dependent text-case attribute (better, a
text-case attribute that can be overridden if the context requires
it): 1. have the implementation look at the context where the citation
occurs, or 2. have some support in CSL - like the one proposed by
Frank.
The first option is error prone and depends on the text format we are
processing. The second one makes CSL more verbose but gives more power
to the user and lets us have an implementation which is really format
independent. Implementing this second approach seems to me not too
difficult.
I think the second solution is a better approach, but I didn’t try to
implement it so take my opinion with care.
Hope my thoughts are somehow useful and related to the discussion.
Andrea
When I ran into this problem, I looked hard at ways of handling it
without touching CSL, but I came up dry. Where there is a need to
capitalize the first letter in a cite, you need to get at the string
before it heads into the formatter, and the only way to do that is
through a CSL declaration of some sort. I think Andrea would tell you
the same thing.Andrea: thoughts?
I feel a bit sorry because I’m not able, at the present time, to
closely follow your discussions (I have a 2 month daughter to whom
I’m dedicating much of my attention).
No problem at all; thanks for the comments!
As far as I understand it I believe that Frank is right.
You need to have some context information in order to decide whether
the first letter of a cite must be capitalized or not. The Haskell
citeproc, at the present time, only receives a list of tuples (made of
the citation and its locator). This is possible because the text-case
attribute is not flexible and context dependent. So, I see 2 ways of
having a flexible and context dependent text-case attribute (better, a
text-case attribute that can be overridden if the context requires
it): 1. have the implementation look at the context where the citation
occurs, or 2. have some support in CSL - like the one proposed by
Frank.The first option is error prone and depends on the text format we are
processing. The second one makes CSL more verbose but gives more power
to the user and lets us have an implementation which is really format
independent. Implementing this second approach seems to me not too
difficult.I think the second solution is a better approach, but I didn’t try to
implement it so take my opinion with care.
But as I understand it, context is important no matter the solution.
You need to know how the string is being inserted in the output, and
that doesn’t change in either of options.
But you don’t need to know the internal details, I’m suggesting.
Consider the following python code, which yields this output:
One | two | three
See four | five | sixOn Sun, Mar 1, 2009 at 6:16 AM, Andrea Rossato <@Andrea_Rossato1> wrote:
On Fri, Feb 27, 2009 at 08:51:42AM -0500, Bruce D’Arcus wrote:
On Fri, Feb 27, 2009 at 8:30 AM, Frank Bennett <@Frank_Bennett> wrote:
===
import string
“”"
A FormattedReference is a list of special string objects.
The show_me method just returns the content of those strings.
For the first string object, however, it title cases it, if there
is no prefix.
“”"
class FormattedString:
def init(self, content, prefix=None):
self.prefix = prefix
self.content = content
class FormattedCitation:
def init(self):
self.data =
def add(self, x):
self.data.append(x)
def show_me(self):
result =
for index, item in enumerate(self.data):
if index == 0:
if item.prefix:
field =
field.append(item.prefix.title())
field.append(item.content)
result.append(’ '.join(field))
else:
result.append(item.content.title())
else:
result.append(item.content)
print(" | ".join(result))
a = FormattedString(content=‘one’)
b = FormattedString(prefix=‘bar’, content=‘two’)
c = FormattedString(prefix=‘bar’, content=‘three’)
d = FormattedString(prefix=“see”, content=‘four’)
e = FormattedString(prefix=‘bar’, content=‘five’)
f = FormattedString(prefix=‘bar’, content=‘six’)
ref = FormattedCitation()
ref2 = FormattedCitation()
ref.add(a)
ref.add(b)
ref.add(c)
ref2.add(d)
ref2.add(e)
ref2.add(f)
ref.show_me()
ref2.show_me()
When I ran into this problem, I looked hard at ways of handling it
without touching CSL, but I came up dry. Where there is a need to
capitalize the first letter in a cite, you need to get at the string
before it heads into the formatter, and the only way to do that is
through a CSL declaration of some sort. I think Andrea would tell you
the same thing.Andrea: thoughts?
I feel a bit sorry because I’m not able, at the present time, to
closely follow your discussions (I have a 2 month daughter to whom
I’m dedicating much of my attention).No problem at all; thanks for the comments!
As far as I understand it I believe that Frank is right.
You need to have some context information in order to decide whether
the first letter of a cite must be capitalized or not. The Haskell
citeproc, at the present time, only receives a list of tuples (made of
the citation and its locator). This is possible because the text-case
attribute is not flexible and context dependent. So, I see 2 ways of
having a flexible and context dependent text-case attribute (better, a
text-case attribute that can be overridden if the context requires
it): 1. have the implementation look at the context where the citation
occurs, or 2. have some support in CSL - like the one proposed by
Frank.The first option is error prone and depends on the text format we are
processing. The second one makes CSL more verbose but gives more power
to the user and lets us have an implementation which is really format
independent. Implementing this second approach seems to me not too
difficult.I think the second solution is a better approach, but I didn’t try to
implement it so take my opinion with care.But as I understand it, context is important no matter the solution.
You need to know how the string is being inserted in the output, and
that doesn’t change in either of options.But you don’t need to know the internal details, I’m suggesting.
Consider the following python code, which yields this output:One | two | three
See four | five | six===
import string“”"
A FormattedReference is a list of special string objects.
The show_me method just returns the content of those strings.
For the first string object, however, it title cases it, if there
is no prefix.
“”"class FormattedString:
def init(self, content, prefix=None):
self.prefix = prefix
self.content = contentclass FormattedCitation:
def init(self):
self.data =
def add(self, x):
self.data.append(x)
def show_me(self):
result =
for index, item in enumerate(self.data):
if index == 0:
if item.prefix:
field =
field.append(item.prefix.title())
field.append(item.content)
result.append(’ '.join(field))
else:
result.append(item.content.title())
else:
result.append(item.content)
print(" | ".join(result))a = FormattedString(content=‘one’)
b = FormattedString(prefix=‘bar’, content=‘two’)
c = FormattedString(prefix=‘bar’, content=‘three’)d = FormattedString(prefix=“see”, content=‘four’)
e = FormattedString(prefix=‘bar’, content=‘five’)
f = FormattedString(prefix=‘bar’, content=‘six’)ref = FormattedCitation()
ref2 = FormattedCitation()ref.add(a)
ref.add(b)
ref.add(c)ref2.add(d)
ref2.add(e)
ref2.add(f)ref.show_me()
ref2.show_me()
Solved in citeproc-js. I still think it’s a harsh design choice for
people trying to implement the spec, though. Certainly it’s possible
to do most anything in software, but if a broad base of
implementations is an objective, gotcha reduction is maybe something
to consider.
Frank
This is a nice solution just because you move the problem outside our
scope: it is the application calling citeproc that has to decide if
something is a prefix that turns off the “capitalize-first” attribute.
Still I find it ugly because the text-case attribute becomes a quite
strange tool: if “capitalize-first” is used than applying it depends
to some other factor, the presence/absence of a prefix, whose nature
is defined outside our scope. That seems to me a call for bug reports
(I’m coming to believe that people writing citation styles are somehow
weird anyhow…:-).
Frank’s proposal, instead, makes everything explicit. I prefer that
solution: it is more verbose but it is more predictable and under our
control.
Anyway I’m not sure I really get all the implications of the problem,
so please take this comment with care.
BTW, Frank, how did you implemented this stuff? svn update didn’t
bring up anything - still at revision 656 here.
Andrea