In part as a result of earlier comments from Andrea about his
implementation, it occurs to me we could drop the substitute element
in favor of the generic cs:choose IF we agree on one simple rule: a
variable may only print once?
The result would be more consistent and simpler.
Is this worth considering? Any arguments against?
Bruce
In part as a result of earlier comments from Andrea about his
implementation, it occurs to me we could drop the substitute element
in favor of the generic cs:choose IF we agree on one simple rule: a
variable may only print once?The result would be more consistent and simpler.
Is this worth considering? Any arguments against?
guess what I’m wanting to ask next is … whether the ability to
print variables twice, if the first one has no names element in its
ancestry, is definitely necessary?
Such, such were the joys.
http://groups.google.com/group/zotero-dev/browse_thread/thread/ef62506f54fd66de#
In citeproc-js, I’ve already adopted one-time-only suppression as a
general principle, regardless of where the first rendering element is
located. This general suppression behavior was the topic of an
exchange with Simon a couple of weeks ago, in connection with Zotero
deployment. He noticed the difference in behavior, I asked for an
example where multiple renderings are needed, and he provided one.
***** Simon *****
Well, one case is:
from APA style. I’m not sure if I can think of any cases where text
variables need to be printed twice, but date variables certainly
should be.
***** /Simon *****
I’ve kept the general block in place, but made date variables a
general exception to it; choose statements and substitute work in
exactly the same way (in fact they’re exactly the same under the
hood).
At the moment, the only foundation for this design choice is my casual
bystander’s assumption that it won’t hurt anything. It’s probably a
good idea to let citeproc-js run interference for you on this one, and
proceed with remangling all of the styles in the repository only if no
problems arise in the wild.
I think label-type of styles usually print (text)-variables multiple
times. E.g. a recent post on the forums:
Don’t know how common those are.
Rintze
***** Simon *****
from APA style. I’m not sure if I can think of any cases where text
variables need to be printed twice, but date variables certainly
should be.
***** /Simon *****I think label-type of styles usually print (text)-variables multiple
In the bibliography we list: Hiatt:1996 [TAB] Hiatt, L. R. ... publication details.
times. E.g. a recent post on the forums:inline [author:1990] & Bibliographic reference - Zotero Forums
Don’t know how common those are.
Fun one. Is this possible even with the current setup?
I tried to answer that question myself, but looking at my (slightly
dated) copy of the CSL spec, I can’t actually find any mention of the
render-only-once behaviour that people refer to in connection with the
substitute element. I implemented it in citeproc-js on the basis of
comments made in mail threads here and on zotero-dev, but I’ve never
seen a full explanation of how it’s supposed to work.
Is there any detailed and clear documentation around on how the names
and substitute elements are meant to suppress subsequent renderings of
a variable? I’m genuinely curious.
Frank
…
Am traveling, but once I return (tonight), I’ll put together an xslt to
incorporate all the changes I’m suggesting.
I’ve checked in the start of this as csl/scripts/update.xsl.
No.
But basically, if a variable is substituted, it can’t be printed again.
The idea I’m floating here would make that explicit, and general (with
possibly an exception for dates).
Bruce
With this change, will it still be possible to localize some of these
options/attributes? E.g. Frank has an example:
http://bitbucket.org/fbennett/citeproc-js/src/29073b81ff8a/locale/locales-en-US.xmlOn Mon, Jul 27, 2009 at 6:36 PM, Bruce D’Arcus<@Bruce_D_Arcus1> wrote:
Result example fragment is:
…
I could imagine something like
Rintze
…
The idea I’m floating here would make that explicit, and general (with
possibly an exception for dates).
I guess thinking about this more, I don’t think it’s a great idea to
remove it. The existing syntax is nice-and-tight, and I think we’re
fine if we just document the damned thing. The same applies to
cs:group, which is also a kind of PITA implementation wise, but still
useful.
Bruce
Yeah, I forgot about this, but it’s something to consider.
But this also raises another issue: right now, there are no global
parameters. We might need to allow them, so that one could do:
***** Simon *****
from APA style. I’m not sure if I can think of any cases where text
variables need to be printed twice, but date variables certainly
should be.
***** /Simon *****I think label-type of styles usually print (text)-variables multiple
In the bibliography we list: Hiatt:1996 [TAB] Hiatt, L. R. ... publication details.
times. E.g. a recent post on the forums:inline [author:1990] & Bibliographic reference - Zotero Forums
Don’t know how common those are.
Fun one. Is this possible even with the current setup?
I tried to answer that question myself, but looking at my (slightly
dated) copy of the CSL spec, I can’t actually find any mention of the
render-only-once behaviour that people refer to in connection with the
substitute element. I implemented it in citeproc-js on the basis of
comments made in mail threads here and on zotero-dev, but I’ve never
seen a full explanation of how it’s supposed to work.Is there any detailed and clear documentation around on how the names
and substitute elements are meant to suppress subsequent renderings of
a variable?No.
But basically, if a variable is substituted, it can’t be printed again.
Got that much.
The idea I’m floating here would make that explicit, and general (with
possibly an exception for dates).
Unless I’m missing something, Rintze’s example above won’t compute
with the current setup, and won’t work in the new processor either.
Maybe there’s a case for a no-suppress attribute?
…
The idea I’m floating here would make that explicit, and general (with
possibly an exception for dates).I guess thinking about this more, I don’t think it’s a great idea to
remove it. The existing syntax is nice-and-tight, and I think we’re
fine if we just document the damned thing. The same applies to
cs:group, which is also a kind of PITA implementation wise, but still
useful.
No complaints here.
Yes, global parameters would be nice. I guess global options specified
in would be overruled by the same options set in
and ?
To keep the style and locale files similar in layout, perhaps we could use this:On Mon, Jul 27, 2009 at 6:50 PM, Bruce D’Arcus<@Bruce_D_Arcus1> wrote:
Yeah, I forgot about this, but it’s something to consider.
But this also raises another issue: right now, there are no global
... or ?
parameters. We might need to allow them, so that one could do:
The locale element would just contain the bare bones structure of a
complete CSL style. I propose using both and , so we
can use the same layout in a style that specifies overriding
locale-terms/options, e.g:
Rintze
I don’t want to push this thread too much off-topic, but that example
also has a problem with second-field-align (i.e. it needs
third-field-align, or arbitrary-field-align). Unless the current
second-field-align would consider a group a single field, e.g.:
But full support for these label-type styles will probably require
more changes. Maybe something for CSL 1.1 :).
Rintze
Unless I’m missing something, Rintze’s example above won’t compute
with the current setup, and won’t work in the new processor either.
True, but I’m fine with that. We’re not going to make 99% of styles
difficult to support one, odd, style.
Maybe there’s a case for a no-suppress attribute?
That might be an option to consider.
Bruce
Unless I’m missing something, Rintze’s example above won’t compute
with the current setup, and won’t work in the new processor either.
Maybe there’s a case for a no-suppress attribute?I don’t want to push this thread too much off-topic, but that example
also has a problem with second-field-align (i.e. it needs
third-field-align, or arbitrary-field-align). Unless the current
second-field-align would consider a group a single field, e.g.:
In citeproc-js, groups are indeed treated as a single “field”.
There’s no other way to handle it (at least while remaining sane).
Bruce has suggested in the forums that these complex formatting
options be replaced with class tags on groups, with some standard
bundle of styling names. That seems like a really (really) good idea.
Things like second-field-align are very difficult to define and
control.
Unless I’m missing something, Rintze’s example above won’t compute
with the current setup, and won’t work in the new processor either.True, but I’m fine with that. We’re not going to make 99% of styles
difficult to support one, odd, style.
Very fair.
Maybe there’s a case for a no-suppress attribute?
That might be an option to consider.
(Just to avoid misunderstanding – I’d not be in a rush for that one.
Uhmz. After taking a second look it seems better to keep out
of , because terms can only be specified within , so
that would make:On Mon, Jul 27, 2009 at 7:18 PM, Rintze Zelle<@Rintze_Zelle> wrote:
To keep the style and locale files similar in layout, perhaps we could use this:
n.d. ---
Rintze