All - we’ve got a little bug in the schema, outlined here:
http://forums.zotero.org/discussion/17742/locators-zotero-216/
Basically, we need to change the ‘sub verbo’ locator value to ‘sub-verso’.
Any objections to doing that ASAP in a minor point release?
I need a +1 or -1 one from all implementors please.
Bruce
Typo correction: “to ‘sub-verbo’.”
In short, CSL allows testing for one or more locator types using the locator
conditional (). Multiple types are
space-delimited, so the locator type “sub verbo” gets incorrectly read as
two types, “sub” and “verbo”.
Rintze
I think squashing this bug in an intermediate release is going to be rather
painful. Seeing as this bug has been around for quite a while (at least
since CSL 0.8.1), I’d recommend postponing the fix to CSL 1.1.
“sub verbo” occurs in the CSL locale files, and the term can be redefined in
styles. We could keep a ‘normal’ “sub verbo” term and create a "sub-verbo"
locator term, but that requires significant schema surgery and CSL
processors would have to link “sub-verbo” to “sub verbo”. Probably not worth
the effort.
RintzeOn Wed, Apr 27, 2011 at 2:56 PM, Rintze Zelle <@Rintze_Zelle>wrote:
All - we’ve got a little bug in the schema, outlined here:
http://forums.zotero.org/discussion/17742/locators-zotero-216/
Basically, we need to change the ‘sub verbo’ locator value to
‘sub-verso’.Typo correction: “to ‘sub-verbo’.”
In short, CSL allows testing for one or more locator types using the
locator conditional (). Multiple types are
space-delimited, so the locator type “sub verbo” gets incorrectly read as
two types, “sub” and “verbo”.I think squashing this bug in an intermediate release is going to be rather
painful. Seeing as this bug has been around for quite a while (at least
since CSL 0.8.1), I’d recommend postponing the fix to CSL 1.1.
I’m in no hurry at all to get to 1.1. AFAIK, two years is a reasonable
time-frame, if not longer. E.g. (feature) stability has to be our
mantra now.
I don’t think we should be content with allowing a simple/dumb bug
like this to hang around for another two years.
“Painful” how? Are there other minor issues like this we can bundle
together into a minor release?
“sub verbo” occurs in the CSL locale files, and the term can be redefined in
styles. We could keep a ‘normal’ “sub verbo” term and create a “sub-verbo”
locator term, but that requires significant schema surgery and CSL
processors would have to link “sub-verbo” to “sub verbo”. Probably not worth
the effort.
The fact remains we have a bug we need to fix. I suggest we do it
quickly and aggressively (a simple search-and-replace on all relevant
files). It’s not exactly a commonly used locator.
Bruce
But it is a common term (it’s in every CSL locale).
Rintze
Seeing as this bug has been around for quite a while (at least since CSL
0.8.1)
Traced back to
Author: erazlogo
Changed paths: 2
Log Message: Adds broadcast type and sub verbo locator
Elena is to blame! 
RintzeOn Wed, Apr 27, 2011 at 3:26 PM, Rintze Zelle <@Rintze_Zelle>wrote:
Date: Thu Jul 31 15:25:19 2008 UTC (2 years, 8 months ago)
“Bruce D’Arcus” <@Bruce_D_Arcus1> writes:
All - we’ve got a little bug in the schema, outlined here:
http://forums.zotero.org/discussion/17742/locators-zotero-216/
Basically, we need to change the ‘sub verbo’ locator value to ‘sub-verso’.
Any objections to doing that ASAP in a minor point release?
I need a +1 or -1 one from all implementors please.
+1 here.–
andrea rossato
It’s really all of our faults, for not being more careful. Really all of the
terms should be tokens.
Seeing as this bug has been around for quite a while (at least since CSL
0.8.1)Traced back to
+1.
Simon
+1 definitely.
All - we’ve got a little bug in the schema, outlined here:
http://forums.zotero.org/discussion/17742/locators-zotero-216/
Basically, we need to change the ‘sub verbo’ locator value to ‘sub-verso’.
Any objections to doing that ASAP in a minor point release?
I need a +1 or -1 one from all implementors please.
~~1
I don’t think there’s a need to rush this. A workaround was used in
2.0.9 (testing for all locator labels that are not “sub verbo”). The
workaround didn’t work in citeproc-js because the locator attribute
was not being handled correctly; with a fix in place, code from 2.0.9
will carry over smoothly.
A change in the term name should be tested in applications before
release. There will be legacy documents around that set “sub verbo” as
the locator label key, so processors will need to remap that to
“sub-verbo” on the fly in any case, to avoid breaking documents, and
we’ll want to be sure the special handling needed works correctly
before the locale files change underneath the processor.
So I think it’s desirable to move “sub verbo” to “sub-verbo”, but I
think the change can wait a bit for testing and reflection.
Frank
All - we’ve got a little bug in the schema, outlined here:
http://forums.zotero.org/discussion/17742/locators-zotero-216/
Basically, we need to change the ‘sub verbo’ locator value to ‘sub-verso’.
Any objections to doing that ASAP in a minor point release?
I need a +1 or -1 one from all implementors please.
~~1
I don’t think there’s a need to rush this. A workaround was used in
2.0.9 (testing for all locator labels that are not “sub verbo”). The
workaround didn’t work in citeproc-js because the locator attribute
was not being handled correctly; with a fix in place, code from 2.0.9
will carry over smoothly.A change in the term name should be tested in applications before
release. There will be legacy documents around that set “sub verbo” as
the locator label key, so processors will need to remap that to
“sub-verbo” on the fly in any case, to avoid breaking documents, and
we’ll want to be sure the special handling needed works correctly
before the locale files change underneath the processor.So I think it’s desirable to move “sub verbo” to “sub-verbo”, but I
think the change can wait a bit for testing and reflection.
I’ve pushed a citeproc-js release that is indifferent to whether “sub
verbo” or “sub-verbo” is used in the locale files, term names within
styles, and item data input. With this revision, for the purposes of
this particular processor, the problem is limited to schema
validation, so (for the purposes of citeproc-js) the schema changes
can take place as and when. Once the revised processor (v. 1.0.157)
reaches production clients, changing the term name in locales and
style files shouldn’t have any special impact citeproc-js systems.
Let me put this is the most straightforward terms possible:
Any style that currently uses “sub verbo” as a condition is completely invalid.
So effectively, for implementations, it’s as if the term doesn’t exist
for purposes of conditional testing (e.g. you shouldn’t be coding
citeproc-js to accept “sub verbo” as a condition in my view because
you’re going out of your way to accept a broken style).
Therefore, I do think there’s some urgency in fixing this; in say the
next couple of weeks. It’s an infrequently enough used term that a
simple search-and-replace on the following repos should suffice:
That, plus rolling in the spec changes in author grouping should be a
reasonable 1.0.1 release.
Bruce
All - we’ve got a little bug in the schema, outlined here:
http://forums.zotero.org/discussion/17742/locators-zotero-216/
Basically, we need to change the ‘sub verbo’ locator value to ‘sub-verso’.
Any objections to doing that ASAP in a minor point release?
I need a +1 or -1 one from all implementors please.
~~1
I don’t think there’s a need to rush this. A workaround was used in
2.0.9 (testing for all locator labels that are not “sub verbo”). The
workaround didn’t work in citeproc-js because the locator attribute
was not being handled correctly; with a fix in place, code from 2.0.9
will carry over smoothly.A change in the term name should be tested in applications before
release. There will be legacy documents around that set “sub verbo” as
the locator label key, so processors will need to remap that to
“sub-verbo” on the fly in any case, to avoid breaking documents, and
we’ll want to be sure the special handling needed works correctly
before the locale files change underneath the processor.So I think it’s desirable to move “sub verbo” to “sub-verbo”, but I
think the change can wait a bit for testing and reflection.Let me put this is the most straightforward terms possible:
Any style that currently uses “sub verbo” as a condition is completely invalid.
So effectively, for implementations, it’s as if the term doesn’t exist
for purposes of conditional testing (e.g. you shouldn’t be coding
citeproc-js to accept “sub verbo” as a condition in my view because
you’re going out of your way to accept a broken style).
I explained why this is necessary, in order into avoid breaking
documents during the migration to the repaired version of the schema.
It’s the processor’s job to serve citations against a valid schema,
and citeproc-js will do that, both before and after the schema is
fixed.
Therefore, I do think there’s some urgency in fixing this; in say the
next couple of weeks. It’s an infrequently enough used term that a
simple search-and-replace on the following repos should suffice:
- docs
- schema
- locales
- styles
That, plus rolling in the spec changes in author grouping should be a
reasonable 1.0.1 release.
Great, will look forward to it.
I just did a quick look, and there’s only one style
(irish-historical-studies.csl) in the git styles repo that uses “sub
verbo”, but it does not use it in a conditional test. Rather, it uses
it to very subtly redefine (one period is removed) the localized short
form of the term.
So for a user of this style, they would see a very minor change in
their documents IF they used a sub verbo locator, until they updated
their style.
Bruce
Considering that we’re all busy, I’m only going to support this if we’re
doing a more comprehensive CSL 1.0.1 release (with review of existing CSL
1.0.1 tickets, some of which can easily be closed). We can combine the “sub
verbo”-renaming with the introduction of support for gender-specific
ordinals using the attribute-based syntax, and branch off the CSL 1.0
locales. I think we can do this in ca. 3 months.
Rintze
Maybe this highlights the point that we need to move to a more agile
way to publish changes. E.g. the process of publishing itself
shouldn’t be a barrier to us making changes we need to make.
What do you mean by “branch off the CSL 1.0 locales”?
Bruce
For gender-specific ordinals, I prefer to use the syntax proposed here:
http://sourceforge.net/mailarchive/message.php?msg_id=26629141
That approach could confuse CSL 1.0 processors (which could use the wrong
ordinal, see
https://github.com/citation-style-language/schema/issues/7#issuecomment-941152),
and CSL locales with the gender-specific ordinals wouldn’t validate
against the CSL 1.0 schema. So I think it might make sense to create a 1.0
branch for the CSL 1.0 locales at
https://github.com/citation-style-language/locales, like we have for the CSL
0.8 locales.
Rintze
So just so I understand …
You’re saying you want to fold in a backward-incompatible feature
addition with a bug fix release?
Bruce
In this context, backward-compatibility is the ability of a CSL 1.0.1
processor to handle CSL 1.0 styles and locales, right? Then only the bug fix
is backward-incompatible (as defining gender-specific ordinals in the CSL
locales will always be optional).
Rintze