Ibid. and ibid.

[Bruce_D_Arcus1]

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

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.

Right, because I’d guess you 'd need it there to consider the context.

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.

But where is that NOT the case? The rule here applies to what I’ve
called footnoted-citations, or citations inserted in footnote using
note styles where there is no preceding text. Isn’t that an ugly
situation regardless?

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.

This (the “more predictable,” etc. bit) is what I’m not yet seeing.

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.

Yeah, we need to document the conclusion of this discussion.

Bruce

[Elena_Razlogova]

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

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.

Right, because I’d guess you 'd need it there to consider the context.

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.

But where is that NOT the case? The rule here applies to what I’ve
called footnoted-citations, or citations inserted in footnote using
note styles where there is no preceding text. Isn’t that an ugly
situation regardless?

That seems to me a call for bug reports
(I’m coming to believe that people writing citation styles are
somehow
weird anyhow…:-).

Again, why not do the opposite–always uppercase the first letter in
the beginning of a footnote instead of turning off the “capitalize-
first” attribute? This way there will be no bug reports because the
uppercasing “lowercase” text-case attribute in the beginning of a
sentence is an exception that everyone would normally expect.

[Frank_Bennett]

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

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,

The changes are between checkins 643 and 646. The tests are in
test_term.js, and the main changes are in state.js and elements.js.
Two term-related issues are treated in that interval, one using the
term_predecessor flag, the other a term_sibling flag. The former is
this item.

The latter flag covers another fun little item:

The cs:group element. Used to provide delimiters and a common

prefix/suffix. If

an item has no fields contained in a group, any elements

will not be printed.

Lawyers will of course instantly recognize that this has two potential
meanings. If memory serves me right, the current Zotero
implementation adopts the broader reading: if you use a localized term
inside a group, and conditional branching yields the term on its own
as the only element in the group – something like, say, Ibid. – you
mysteriously get no error and no output. I have adopted the narrower
reading: the term is suppressed only if there is at least one Item
content variable within the scope of the group that attempts to
render, but fails for lack of content, and no Item field successfully
renders. It’s not clear from the face of the comment why this is in
there, but, you know, rules are rules. I just work here.

Frank

[Bruce_D_Arcus1]

The changes are between checkins 643 and 646. The tests are in
test_term.js, and the main changes are in state.js and elements.js.
Two term-related issues are treated in that interval, one using the
term_predecessor flag, the other a term_sibling flag. The former is
this item.

Can you respond to the points that Elena and I have raised Frank? You
made a claim that this imposes an implementation hurdle, and as of
yet, I do not understand how.

The latter flag covers another fun little item:

The cs:group element. Used to provide delimiters and a common

prefix/suffix. If

an item has no fields contained in a group, any elements

will not be printed.

Lawyers will of course instantly recognize that this has two potential
meanings. If memory serves me right, the current Zotero
implementation adopts the broader reading: if you use a localized term
inside a group, and conditional branching yields the term on its own
as the only element in the group – something like, say, Ibid. – you
mysteriously get no error and no output. I have adopted the narrower
reading: the term is suppressed only if there is at least one Item
content variable within the scope of the group that attempts to
render, but fails for lack of content, and no Item field successfully
renders.

No, that is incorrect. We need to change the text to make clear that
there must be at least one non-null variable or macro call result.

There’s a thread in the archives where I explained to Andrea that
cs:group is effectively syntactic sugar for a more complex conditional
that tests for the presence of any child varaible or macro calls.

It’s not clear from the face of the comment why this is in
there, but, you know, rules are rules.

The use case is simple. Consider output like “avaialble from: ,” where
what follows may be either a physical or an online location. Or a
publisher group where you want “New York:ABC Books” but there may be
cases where you have no publisher.

Bruce

[Frank_Bennett]

The changes are between checkins 643 and 646. The tests are in
test_term.js, and the main changes are in state.js and elements.js.
Two term-related issues are treated in that interval, one using the
term_predecessor flag, the other a term_sibling flag. The former is
this item.

Can you respond to the points that Elena and I have raised Frank? You
made a claim that this imposes an implementation hurdle, and as of
yet, I do not understand how.

The latter flag covers another fun little item:

The cs:group element. Used to provide delimiters and a common

prefix/suffix. If

an item has no fields contained in a group, any elements

will not be printed.

Lawyers will of course instantly recognize that this has two potential
meanings. If memory serves me right, the current Zotero
implementation adopts the broader reading: if you use a localized term
inside a group, and conditional branching yields the term on its own
as the only element in the group – something like, say, Ibid. – you
mysteriously get no error and no output. I have adopted the narrower
reading: the term is suppressed only if there is at least one Item
content variable within the scope of the group that attempts to
render, but fails for lack of content, and no Item field successfully
renders.

No, that is incorrect. We need to change the text to make clear that
there must be at least one non-null variable or macro call result.

“That is incorrect” is ambiguous. Please be specfic. I pointed out
two possible interpretations. Are both incorrect, or only one, and if
so, which?

There’s a thread in the archives where I explained to Andrea that
cs:group is effectively syntactic sugar for a more complex conditional
that tests for the presence of any child varaible or macro calls.

And there’s probably lots of other information in Google. The point
is that threading the needle can end up consuming large amounts of a
scarce resource in your chain of production.

[Frank_Bennett]

The changes are between checkins 643 and 646. The tests are in
test_term.js, and the main changes are in state.js and elements.js.
Two term-related issues are treated in that interval, one using the
term_predecessor flag, the other a term_sibling flag. The former is
this item.

Can you respond to the points that Elena and I have raised Frank? You
made a claim that this imposes an implementation hurdle, and as of
yet, I do not understand how.

I’ve implemented it. I can’t do better than that. If it breaks other
implementations, the people running them will be able to explain. It
sounds like Andrea may have such an issue.

The latter flag covers another fun little item:

The cs:group element. Used to provide delimiters and a common

prefix/suffix. If

an item has no fields contained in a group, any elements

will not be printed.

Lawyers will of course instantly recognize that this has two potential
meanings. If memory serves me right, the current Zotero
implementation adopts the broader reading: if you use a localized term
inside a group, and conditional branching yields the term on its own
as the only element in the group – something like, say, Ibid. – you
mysteriously get no error and no output. I have adopted the narrower
reading: the term is suppressed only if there is at least one Item
content variable within the scope of the group that attempts to
render, but fails for lack of content, and no Item field successfully
renders.

No, that is incorrect. We need to change the text to make clear that
there must be at least one non-null variable or macro call result.

There’s a thread in the archives where I explained to Andrea that
cs:group is effectively syntactic sugar for a more complex conditional
that tests for the presence of any child varaible or macro calls.

If that’s the case, the specification should say so.

It’s not clear from the face of the comment why this is in
there, but, you know, rules are rules.

The use case is simple. Consider output like “avaialble from: ,” where
what follows may be either a physical or an online location. Or a
publisher group where you want “New York:ABC Books” but there may be
cases where you have no publisher.

Please add this to the spec, then.

[Bruce_D_Arcus1]

Given the following text, the ambiguous “that” reference refers to the second.

Bruce

[Bruce_D_Arcus1]

The changes are between checkins 643 and 646. The tests are in
test_term.js, and the main changes are in state.js and elements.js.
Two term-related issues are treated in that interval, one using the
term_predecessor flag, the other a term_sibling flag. The former is
this item.

Can you respond to the points that Elena and I have raised Frank? You
made a claim that this imposes an implementation hurdle, and as of
yet, I do not understand how.

I’ve implemented it. I can’t do better than that. If it breaks other
implementations, the people running them will be able to explain. It
sounds like Andrea may have such an issue.

So let me get this straight …

You make a somewhat loaded claim that this is an unreasonable burden
to implement. Andrea appears to agree, and says he worries it will
yield bug reports.

Elena and I are simply not understanding why you guys are saying this;
and asking you to clarify.

But you can’t/won’t?

Fine; I’ll simply add some text that reflects my understanding of the
issue to the schema.

The latter flag covers another fun little item:

The cs:group element. Used to provide delimiters and a common

prefix/suffix. If

an item has no fields contained in a group, any elements

will not be printed.

Lawyers will of course instantly recognize that this has two potential
meanings. If memory serves me right, the current Zotero
implementation adopts the broader reading: if you use a localized term
inside a group, and conditional branching yields the term on its own
as the only element in the group – something like, say, Ibid. – you
mysteriously get no error and no output. I have adopted the narrower
reading: the term is suppressed only if there is at least one Item
content variable within the scope of the group that attempts to
render, but fails for lack of content, and no Item field successfully
renders.

No, that is incorrect. We need to change the text to make clear that
there must be at least one non-null variable or macro call result.

There’s a thread in the archives where I explained to Andrea that
cs:group is effectively syntactic sugar for a more complex conditional
that tests for the presence of any child varaible or macro calls.

If that’s the case, the specification should say so.

Hence the “we need to change the text” comment above

Bruce

[Bruce_D_Arcus1]

OK, changes to schema documentation:

1. cs:group

Group is used to provide delimiters and a common prefix/suffix.

It is syntactic

sugar for a conditional that tests for the presence of any

non-null child variable

or macro call result. So if there no such results, then any <text

term="(term)">

content will not be printed.

2. cs:citation

The cs:citation handles printing of citations. A citation may consist of

one-or-more references to bibliographic sources. These references

can either

be simple in-text keys [doe99] or numeric markers [1], or more

complex short

descriptors generated at runtime common in author-date (Doe,

1999a) or note-based

styles.

note: one issue unique to note-based styles is that a citation reference

effectively may become a full sentence. Implementers should

consider this in

their design and insert the final formatted citation in the

correct title form.

For example, if a citation is footnoted without any additional

text, the first

character of the output should be uppercased. By contrast, if the

citation is

within a pre-existing footnote, and preceded by non-citation

text, then it should

be printed as is.

If there’s some practical problem that results from this, or if it
otherwise becomes clear this is a bad idea, we can change it later.

Bruce

[Andrea_Rossato1]

I’m not talking about an unreasonable burden: I just think that having
an explicit option to fine-tune any exceptions to the text-case
attribute may prevent any bug report.

That is to say, given a prefix to a citation (for instance “See idem”,
where "See " is the prefix), the ability to decide whether “idem” must
be capitalized directly from CSL may be a better solution - where
better means “let the user decide”.

Since I didn’t try to implement it I’m not analyzing the problem under
the implementation perspective. With regard to this problem - and
following the discussion we have on the pandoc side about improving
its citation support - I’m coming to believe that Bruce may be right
when he says he doesn’t see any difference.

Hope this clarifies my point of view.

Andrea