Julian Onions wrote:
It makes the code slightly harder, but its doable. I’ll let you know if not.
As I said, I’m not wedded to this solution. It’s just what I came up with.
I won’t be able to work on this for the next week, so feel free to
experiment with different options if you feel the need in the meantime.
Bruce
I’m kind of unclear on the advantage of a datatype attribute. At this
point, an “is-number” attribute should suffice, and a separate “is-
date” attribute could be added if necessary. To tie together the
"datatype" and “variable” attributes seems to run contrary to the
current workings of the conditional, namely that each attribute
represents a separate comparison. This is, I believe, more complicated
than Julian’s initial proposal, with little advantage.
Simon
So change it. As I’ve said twice, I’m not wedded to what I checked
in., and I was in a hurry. I don’t have time to deal with this for
another week, so someone else should.
Bruce
Shall I attempt an isnumber, isdate variant?
Julian.
Shall I attempt an isnumber, isdate variant?
If you could, that would be great. I think isdate might be better for
dates, although I’m still not entirely sure how it would work. Elena
OK - will give it a go.
I assume isdate will return true if the field as a whole parses as a valid
date.
so would be true for 1/1/2001 but false for c.1900-1902
Julian.
It seems like Bruce is relatively apathetic, so I changed the schema
to add is-date and is-number attributes (with a hyphen, since this
seems more consistent with the rest of the schema, but I don’t care
too much). I also made line-spacing and entry-spacing s,
rather than attributes on , because in revisiting this
modification in preparation to implement it in Zotero, this approach
seemed more appropriate.
Simon
OK- have changed cite to process the new terms - will upload new csl files
appropriately modified (good old perl!).
Julian.
I’m sure you’ve thought about this but, while 1/1/2001 is unambiguous
1/2/2001 or similar, is ambiguous (mm/dd or dd/mm?) and therefore
shouldn’t parse as a date (yeah, you could use a person’s Locale
settings but this data could be coming from anywhere, so that would be
pretty arbitrary).
Perhaps one could flag this somehow in the UI somewhere and have the
user try to resolve it, but silently parsing it seems a mistake to
me. Of course there’s only a small range that is ambiguous (20/1/2005
isn’t nor is 2/2005 ie just a month), but worth thinking about, I feel.
Another option might be to just parse the unambiguous parts (in this
example just the year).
–J
btw, yay for 2005-01-01 format 
Ah, I have email access.
Um, I included the date datatype option just as an obvious
possibility. I hadn’t thought through how it might be used. If nobody
can envision a real use case, just drop it probably.
Bruce
It seems like Bruce is relatively apathetic,
How about “ambivalent” 
so I changed the schema
to add is-date and is-number attributes (with a hyphen, since this
seems more consistent with the rest of the schema, but I don’t care
too much). I also made line-spacing and entry-spacing s,
rather than attributes on , because in revisiting this
modification in preparation to implement it in Zotero, this approach
seemed more appropriate.
I don’t recall the details of how this was implemented in CSL, but
would just repeat my previous suggestion that where possible this sort
of formatting should be achieved via styles/classes, rather than
inline formatting.
Bruce