While setting up a test for a bug query against the MHRA style, I
found the processor throwing cites like Smith, “Book A”, 2000
[accessed n.d.].
The style renders the URL and the access date without conditional
wrappers, on the assumption that (a) if the URL is nil, access date
will also be nil; and (b) a nil date will render nothing. The CSL 1.0
specification calls for empty dates to render the “no date” term,
hence the output above.
This will be a common issue in styles. In the repository, 60 styles
use the “accessed” term, and 102 styles use the “accessed” variable.
It can be protected against with a conditional wrapper that tests for
the “accessed” variable, but unfortunately it’s not super-simple to
apply. The code in this case looks like this:
Fixing the style in this case requires a conditional wrapper around
the enclosing group (or around both the cs:text and cs:date nodes) –
if only cs:date is wrapped, you get the “accessed” term in the output,
because no attempt is made to render a variable partner within the
scope of the group.
This may get kind of messy. A simpler solution would be to block the
"no date" substitution behavior for the “accessed” variable, inside
the processor. I think that would be safe – at least I can’t think
of any cases in which someone would want “accessed” to render as
"n.d.". It would save a lot of work and a lot of code lines, since
all that would be required is a mention in the specification, and a
one-line change to the processor code.
I also noticed that the “no date” substitution behavior isn’t
mentioned in the upgrade notes. It’s a significant change (and a good
one, I still think), so maybe it should be mentioned there.
On both counts, I can merge in some proposed language for review, if desired.
Frank
While setting up a test for a bug query against the MHRA style, I
found the processor throwing cites like Smith, “Book A”, 2000
[accessed n.d.].
The style renders the URL and the access date without conditional
wrappers, on the assumption that (a) if the URL is nil, access date
will also be nil; and (b) a nil date will render nothing. The CSL 1.0
specification calls for empty dates to render the “no date” term,
hence the output above.
Hmm … I must have entirely missed this, or forgotten about it.
Before we move on, I have an uncomfortable question to ask:
I wonder if this is a good idea in general. Isn’t it better to require
style authors to code for adding “n.d.” in general?
Bruce
While setting up a test for a bug query against the MHRA style, I
found the processor throwing cites like Smith, “Book A”, 2000
[accessed n.d.].
The style renders the URL and the access date without conditional
wrappers, on the assumption that (a) if the URL is nil, access date
will also be nil; and (b) a nil date will render nothing. The CSL 1.0
specification calls for empty dates to render the “no date” term,
hence the output above.
Hmm … I must have entirely missed this, or forgotten about it.
Before we move on, I have an uncomfortable question to ask:
I wonder if this is a good idea in general. Isn’t it better to require
style authors to code for adding “n.d.” in general?
You might be right. I don’t remember the details, but here’s a thread
where this came up, back in September of last year:
It looks like I missed the fact that nothing is possible with
default-n.d. that isn’t also possible with default-empty + term.
There was a lot of stuff going on around dates at that time, this may
have come in with other proposals or changes.
Since we’re poised on the verge of a specification update, that
sentence could be pulled out. Dialling the code out of the processor
isn’t hard. So the option of backing away from this is there,
depending on what everyone thinks.
Frank
I wonder if this is a good idea in general. Isn’t it better to require
style authors to code for adding “n.d.” in general?
You might be right. I don’t remember the details, but here’s a thread
where this came up, back in September of last year:
Other options for date (in press etc...) - Zotero Forums
It seems to have snuck in along some other stuff:
http://sourceforge.net/mailarchive/message.php?msg_id=53208a5f0909291446u77695a8clfae8337a5fc1dfb%40mail.gmail.com
I couldn’t find any discussion on it.
So the option of backing away from this is there,
depending on what everyone thinks.
I support scrapping the feature.
RintzeOn Mon, May 24, 2010 at 9:21 PM, Frank Bennett <@Frank_Bennett>wrote:
I wonder if this is a good idea in general. Isn’t it better to require
style authors to code for adding “n.d.” in general?
You might be right. I don’t remember the details, but here’s a thread
where this came up, back in September of last year:
Other options for date (in press etc...) - Zotero Forums
It seems to have snuck in along some other stuff:
http://sourceforge.net/mailarchive/message.php?msg_id=53208a5f0909291446u77695a8clfae8337a5fc1dfb%40mail.gmail.com
I couldn’t find any discussion on it.
So the option of backing away from this is there,
depending on what everyone thinks.
I support scrapping the feature.
I’ve adjusted the tests and fixed up the code of citeproc-js to
eliminate the behavior.
Frank
Spec amended: http://bitbucket.org/bdarcus/csl-docs/changeset/8dfe31ed8555
RintzeOn Tue, May 25, 2010 at 12:05 AM, Frank Bennett <@Frank_Bennett>wrote: