Bruce, sorry to bomb you like this, but I had some additional
questions while reading the schema:
-
the plural attribute can be set for term and for label. I guess that
for term, the plural attribute allows you to choose between the
single/multiple forms of the term, right? The thing here is that the
"contextual" option (currently only implemented in csl-core), which
makes a lot of sense for label, doesn’t make any sense for term, but
it can be set anyway. Not sure something has to be done about this.
-
is the ability to to display multiple variables in a single text or
date element really useful (e.g. )?
I’d much rather use the delimiter to delimite date-parts (for which
currently no delimiter can be set).
-
the seems too ill-defined. I’d suggest
either to: a) scrap it, b) to change it to something useful (e.g.
“time”), c) or to clearly describe in the spec how implementations
should cope with it.
-
@line 466-468 in
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/csl/schema/trunk/csl.rnc?view=markup:
“When used in a conditional, number tests if there is a number
present, allowing conditional formatting.” From reading the schema’s
description of the choose element, I can’t figure out how you can test
a number in the conditional other than with is-numeric. But is-numeric
tests if the entire string can be parsed as a number, not whether a
number is present in the string (e.g. “12th edition” should fail for
is-numeric, right?).
-
@line 800-803 in
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/csl/schema/trunk/csl.rnc?view=markup:
“If text inside an block can be used to
differentiate two otherwise identical citations, it will be added. If
the citations remain identical after its addition, it will not be
added.” I don’t understand how this works. Is this test available both
in citation clusters as well as in
bibliographies? And doesn’t the test compare all the citations,
instead of pair-wise comparisons (“two otherwise identical
citations”). It’s very well possible to have more than two citations
that are the same, so I don’t understand the “two” here.
-
citation-label is a variable, but how is it assigned? I couldn’t
find any explanation in the schema or on the mailing-list.
Rintze
Bruce, sorry to bomb you like this, but I had some additional
questions while reading the schema:
- the plural attribute can be set for term and for label. I guess that
for term, the plural attribute allows you to choose between the
single/multiple forms of the term, right? The thing here is that the
“contextual” option (currently only implemented in csl-core), which
makes a lot of sense for label, doesn’t make any sense for term, but
it can be set anyway. Not sure something has to be done about this.
Your reading makes some sense. Any other opinions?
FWIW, it seems “contextual” isn’t used at all in the zotero repo.
- is the ability to to display multiple variables in a single text or
date element really useful (e.g. )?
I’d much rather use the delimiter to delimite date-parts (for which
currently no delimiter can be set).
Well, leave this aside until we settle the new date stuff.
- the seems too ill-defined. I’d suggest
either to: a) scrap it, b) to change it to something useful (e.g.
“time”), c) or to clearly describe in the spec how implementations
should cope with it.
It’s stuff like “Fall”.
-
@line 466-468 in
XBib download | SourceForge.net
“When used in a conditional, number tests if there is a number
present, allowing conditional formatting.” From reading the schema’s
description of the choose element, I can’t figure out how you can test
a number in the conditional other than with is-numeric. But is-numeric
tests if the entire string can be parsed as a number, not whether a
number is present in the string (e.g. “12th edition” should fail for
is-numeric, right?).
-
@line 800-803 in
XBib download | SourceForge.net
“If text inside an block can be used to
differentiate two otherwise identical citations, it will be added. If
the citations remain identical after its addition, it will not be
added.” I don’t understand how this works. Is this test available both
in citation clusters as well as in
bibliographies? And doesn’t the test compare all the citations,
instead of pair-wise comparisons (“two otherwise identical
citations”). It’s very well possible to have more than two citations
that are the same, so I don’t understand the “two” here.
I didn’t write the two pieces above. Simon?
- citation-label is a variable, but how is it assigned? I couldn’t
find any explanation in the schema or on the mailing-list.
It should be in the data (though there have been requested which
suggest it might be generate at runtime using different algorithms).
Bruce
That’s because the option is new:
http://sourceforge.net/apps/trac/xbiblio/changeset/988 &
http://sourceforge.net/tracker/?func=detail&atid=678021&aid=2172202&group_id=117435
Would it be a solution to specify the possible values of ‘plural’ as
needed? E.g. instead of
(http://sourceforge.net/apps/trac/xbiblio/browser/csl/schema/branches/split/csl-core.rnc)
419 ## adds a localized term
420 attribute term { cs-terms },
421 attribute form { cs-term-forms }?,
422 include-period,
423 plural?)
460 label-primitives =
461 formatting,
462 include-period?,
463 attribute form { cs-term-forms },
464
465 ##
So you’re suggesting ‘contextual’ is default? If yes, might better as
a Boolean?
Fine with me.
Could do. Might consider doing the same with delimiter-precedes-last,
for consistency.
I haven’t looked at this in awhile. Can you just clarify? Are you
saying there’s something “contextual” about this feature that should
be default?
Bruce
So you’re suggesting ‘contextual’ is default? If yes, might better as
a Boolean?
Fine with me.
Could do. Might consider doing the same with delimiter-precedes-last,
for consistency.
I haven’t looked at this in awhile. Can you just clarify? Are you
saying there’s something “contextual” about this feature that should
be default?
delimiter for the last name is a list
attribute delimiter-precedes-last {
## The "always" value means that result is "J. Doe, and T. Timmons"
"always"
>
## Default behavior; would result in "J. Doe and T.
Timmons," but “J. Doe,
## S. Smith, and T. Timmons” (note comma preceding ‘and’).
“never”
}?,
So by default the comma is inserted before “and” in a nameset with
three names, but not in a nameset with two.
The suggestion is that if the two options to “plural” are true/false,
it would be consistent to set this with true/false as well. It’s not
a backward compatible change, and I’m not pushing.
OK.
Main thing is clarity and consistency, so it might be worth changing,
and this is easy to adjust in the code…
Bruce
Yeah, I suppose he has a point.
Bruce
What about:
for terms: attribute plural { xsd:boolean }? (defaults to “false”)
for labels: attribute pluralize { “always” | “never” | “contextual” }
(defaults to “contextual”)
for delimiter-precedes-last: attribute delimiter-precedes-last { “always” |
“never” | “contextual”}? (defaults to “contextual”)
Having the contextual-option makes it clear the latter two are not boolean
options, while having the different names “plural” and “pluralize” helps
distinguishing the two different behaviors.
Rintze
…
What about:
for terms: attribute plural { xsd:boolean }? (defaults to “false”)
for labels: attribute pluralize { “always” | “never” | “contextual” }
(defaults to “contextual”)
for delimiter-precedes-last: attribute delimiter-precedes-last { “always” |
“never” | “contextual”}? (defaults to “contextual”)
Having the contextual-option makes it clear the latter two are not boolean
options, while having the different names “plural” and “pluralize” helps
distinguishing the two different behaviors.
I’m losing track of this. Can you tell me:
a) whether the above differs from he current schema, and how?
b) the difference between “plural” and “pluralize” here?
Bruce
In CSL 0.8:
Labels and terms both use “plural = attribute plural { xsd:boolean }”. If
the value of plural is not set, the behavior is contextual (in the case of
labels).
http://sourceforge.net/apps/trac/xbiblio/browser/csl/schema/tags/0.8/csl.rnc?rev=768#L599
For delimiter-precedes-last:
attribute delimiter-precedes-last { “always” | “never”}?
http://sourceforge.net/apps/trac/xbiblio/browser/csl/schema/tags/0.8/csl.rnc?rev=768#L321
There are two separate but related issues with all this:
- plural and delimiter-precedes-last can both be seen as booleans
defaulting to a third value. Which might be confusing and therefore
undesirable.
- the default value of plural for terms can’t be contextual, as terms are
context-insensitive (right?). I just tested how Zotero currently copes with
this, and apparently it defaults to “false” for terms.
b) the difference between “plural” and “pluralize” here?
If we want to fix 1, we need explicit contextual-options. As this doesn’t
make sense for plural when used for terms, I suggested using different
attributes: “plural” for terms, which is a true boolean, and “pluralize” for
labels, which has the contextual option. If 1) doesn’t need fixing, this all
isn’t needed. We’d just have to specify that the default value of plural is
contextual for labels, and false for terms.
Rintze
I’ve committed a patch to the schema to wrap this up. I decided to use
plural for both terms and labels. My earlier proposal to stress the
difference in options by using plural/pluralize was too confusing, and there
are other cases where an attribute has different values depending on the
context (e.g. “form”).
http://sourceforge.net/apps/trac/xbiblio/changeset/1112
Rintze
- is the ability to to display multiple variables in a single text or
date element really useful (e.g. )?
I’d much rather use the delimiter to delimite date-parts (for which
currently no delimiter can be set).
Well, leave this aside until we settle the new date stuff.
I checked the styles, and none use two or more variables in either
cs:text or cs:date. So I would like to reiterate that
IMHO it would be much cleaner to eliminate this ability, and to
reserve the delimiter attribute of cs:date for delimiting date-part
elements.
- the seems too ill-defined. I’d suggest
either to: a) scrap it, b) to change it to something useful (e.g.
“time”), c) or to clearly describe in the spec how implementations
should cope with it.
It’s stuff like “Fall”.
So, does Zotero parse “Fall 2000” as { year: 2000, other:Fall }? Or
does it pass on the entire string as something that can’t be parsed
cleanly?
Rintze
It parses { year: 2000, other: “Fall” }, but it only uses the known date
parts. Once https://www.zotero.org/trac/ticket/888 is closed along with
the new processor, it will just pass “Fall 2000” as a literal. My
understanding is that this literal string will be mutually exclusive
with the other date-parts, so we’ll want to enforce that in the schema,
and we should probably change the name.
I think it should be sufficient to drop the “other” date-part, and
(re)-introduce a conditional to test whether a date is presented as a
literal or a parsed date (maybe “is-parsed-date”?). If the conditional
fails, the date can be shown using cs:text.
(localized date)
Rintze
- the seems too ill-defined. I’d suggest
either to: a) scrap it, b) to change it to something useful (e.g.
“time”), c) or to clearly describe in the spec how implementations
should cope with it.
It’s stuff like “Fall”.
So, does Zotero parse “Fall 2000” as { year: 2000, other:Fall }? Or
does it pass on the entire string as something that can’t be parsed
cleanly?
It parses { year: 2000, other: “Fall” }, but it only uses the known date
parts. Once #888 ("is-date" should return "true" only if date parses cleanly) – Zotero is closed along with
the new processor, it will just pass “Fall 2000” as a literal. My
understanding is that this literal string will be mutually exclusive
with the other date-parts, so we’ll want to enforce that in the schema,
and we should probably change the name.
I think it should be sufficient to drop the “other” date-part, and
(re)-introduce a conditional to test whether a date is presented as a
literal or a parsed date (maybe “is-parsed-date”?). If the conditional
fails, the date can be shown using cs:text.
(localized date)
There might be cases where you want different formatting when the
parse fails, I guess, but in most cases (like your example above) the
literal can be passed through by the date element itself, with the
same styling as a “proper” date. In other words, the above could be
expressed simply as:
without losing anything. … ?