That would be inconsistent with is-numeric.
RintzeOn Sun, Aug 30, 2009 at 2:11 PM, Frank Bennett <@Frank_Bennett>wrote:
I’m fine with that.
Bruce
I’m not comfortable with that. To turn this around, what’s wrong with
keeping things as is?
Bruce
string to the CSL processor when it is unable to parse it into the various
date-part elements (year, month, day). So there wouldn’t be any situation in
which the “other” date-part would receive a value.
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
(localized date)
(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.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. … ?
That would be inconsistent with is-numeric.
So the idea is to restore is-date, and have the date element render
nothing if the string doesn’t parse, so that you have to use is-date?
Or is the option meant to offer an alternative way of rendering a
non-parsing date string?
In either case, I guess a remaining question would be how should be rendered when the date does parse.
Should it mirror the behavior of the date element, and deliver
nothing? Or should it have some default rendering that it delivers
(2000-01-30 maybe?) … unless it doesn’t parse, in which case it
should deliver literal instead.
I’m easy either way, but it seems like requiring a condition to
render the literal would require changes to lots of style files. Not
sure if you want to go there.
Here’s the recent ticket that ended in the deletion of the is-date option:
http://sourceforge.net/tracker/?func=detail&atid=678021&aid=2830054&group_id=117435
Frank
I don’t like the idea of passing the entire date as (unstructured,
completely dumb) string to the processor, and so having CSL design
driven by that design choice.
My implementation requires dates to conform to particular structured
date representations, and the way I’m going now will allow the "other"
part to be defined (e.g. “2000///Fall”).
Bruce
- 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”?).I’m not comfortable with that. To turn this around, what’s wrong with
keeping things as is?From what I understand, the idea is that Zotero will pass the entire date
string to the CSL processor when it is unable to parse it into the various
date-part elements (year, month, day). So there wouldn’t be any situation in
which the “other” date-part would receive a value.I don’t like the idea of passing the entire date as (unstructured,
completely dumb) string to the processor, and so having CSL design
driven by that design choice.My implementation requires dates to conform to particular structured
date representations, and the way I’m going now will allow the “other”
part to be defined (e.g. “2000///Fall”).
How do you determine what the relative ordering of the date elements
and the “order” part is? If it always comes before or always after,
you’re going to leave cases uncovered, no?
- 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”?).I’m not comfortable with that. To turn this around, what’s wrong with
keeping things as is?From what I understand, the idea is that Zotero will pass the entire date
string to the CSL processor when it is unable to parse it into the various
date-part elements (year, month, day). So there wouldn’t be any situation in
which the “other” date-part would receive a value.I don’t like the idea of passing the entire date as (unstructured,
completely dumb) string to the processor, and so having CSL design
driven by that design choice.My implementation requires dates to conform to particular structured
date representations, and the way I’m going now will allow the “other”
part to be defined (e.g. “2000///Fall”).How do you determine what the relative ordering of the date elements
and the “order” part is? If it always comes before or always after,
you’re going to leave cases uncovered, no?
There’s also a problem with date ranges, which are supported in the
date element. I don’t think you can avoid literal passthrough in the
short term. Too many breaking pitches.
Frank
(sorry for the extra traffic, but that last message should have said
"date ranges, which are _not supported in the date element")
…
There’s also a problem with date ranges, which are supported in the
date element.
“2002-10/2002-11”
I don’t think you can avoid literal passthrough in the
short term. Too many breaking pitches.
I disagree.
Bruce
So long as the dates passed to the processor conform to the datatype,
it’ll be fine. The datatype supports ranges and approximate dates, as
well as the “other” modifier.
There may be an issue not so much of where the other part goes on
input, but on output (?).
Bruce
How do you determine what the relative ordering of the date elements
and the “order” part is? If it always comes before or always after,
you’re going to leave cases uncovered, no?So long as the dates passed to the processor conform to the datatype,
it’ll be fine. The datatype supports ranges and approximate dates, as
well as the “other” modifier.There may be an issue not so much of where the other part goes on
input, but on output (?).
Yes, it’s output that’s the problem – input isn’t a concern, because
we assume everything will be pre-parsed…
In 250BC, is BC an “other”? If so , how to tell the difference
between “Fall” and “BC”?
A further issue is how such a date should be handled when form=“numeric”?
I’m not fundamentally committed to literal passthrough; and I can see
the advantages of handling things in a structured way. But there are
lots of possibilities in the data, and I want to be sure they’re all
covered.
How do you determine what the relative ordering of the date elements
and the “order” part is? If it always comes before or always after,
you’re going to leave cases uncovered, no?So long as the dates passed to the processor conform to the datatype,
it’ll be fine. The datatype supports ranges and approximate dates, as
well as the “other” modifier.There may be an issue not so much of where the other part goes on
input, but on output (?).Yes, it’s output that’s the problem – input isn’t a concern, because
we assume everything will be pre-parsed…In 250BC, is BC an “other”?
No; iso dates support BC. Example: “-0250” (though there may be
something about counting backwards where you have no year zero?).
If so , how to tell the difference
between “Fall” and “BC”?
As above; not a problem.
A further issue is how such a date should be handled when form=“numeric”?
Am not quite following. Can you try again?
I’m not fundamentally committed to literal passthrough; and I can see
the advantages of handling things in a structured way. But there are
lots of possibilities in the data, and I want to be sure they’re all
covered.
Bruce
How do you determine what the relative ordering of the date elements
and the “order” part is? If it always comes before or always after,
you’re going to leave cases uncovered, no?So long as the dates passed to the processor conform to the datatype,
it’ll be fine. The datatype supports ranges and approximate dates, as
well as the “other” modifier.There may be an issue not so much of where the other part goes on
input, but on output (?).Yes, it’s output that’s the problem – input isn’t a concern, because
we assume everything will be pre-parsed…In 250BC, is BC an “other”?
No; iso dates support BC. Example: “-0250” (though there may be
something about counting backwards where you have no year zero?).
There are a bunch of issues in this that I don’t know how to cover.
Unfortunately, with a heavy teaching term coming up, I won’t have time
to deal with them on my own. I’ll need to know what the incoming data
will look like. I’ll also need to know how much of ISO-8601 is to be
implemented in the processor (time zones?). CSL will need to be
extended to include styling for some new elements (some styles will
put formatting on the BC, so I guess it’s a separate element?). The
handling of date ranges in various permutations (which isn’t part of
ISO-8601, I guess?) needs to be sorted out. And lots of tests need to
be written.
Is this for CSL 1.0?
…
There are a bunch of issues in this that I don’t know how to cover.
Unfortunately, with a heavy teaching term coming up, I won’t have time
to deal with them on my own. I’ll need to know what the incoming data
will look like. I’ll also need to know how much of ISO-8601 is to be
implemented in the processor (time zones?). CSL will need to be
extended to include styling for some new elements (some styles will
put formatting on the BC, so I guess it’s a separate element?). The
handling of date ranges in various permutations (which isn’t part of
ISO-8601, I guess?) needs to be sorted out. And lots of tests need to
be written.Is this for CSL 1.0?
We document what we cover now: year, month, day, other.
If there’s an obvious and easy way to include BC, circa, and ranges,
then we add them now.
If not (which is highly likely), then we put it off until some later date.
I think it highly unlikely we’ll support times, and hence timezones.
Bruce
…
There are a bunch of issues in this that I don’t know how to cover.
Unfortunately, with a heavy teaching term coming up, I won’t have time
to deal with them on my own. I’ll need to know what the incoming data
will look like. I’ll also need to know how much of ISO-8601 is to be
implemented in the processor (time zones?). CSL will need to be
extended to include styling for some new elements (some styles will
put formatting on the BC, so I guess it’s a separate element?). The
handling of date ranges in various permutations (which isn’t part of
ISO-8601, I guess?) needs to be sorted out. And lots of tests need to
be written.Is this for CSL 1.0?
We document what we cover now: year, month, day, other.
If there’s an obvious and easy way to include BC, circa, and ranges,
then we add them now.If not (which is highly likely), then we put it off until some later date.
Sounds good. There will still be some small issues to resolve, but if
ranges and the other others can be pushed forward to a future release,
that will help keep things manageable.
Frank
So no further changes for cs:date in CSL 1.0? None of the current styles use
"other", btw. Should we keep “other” outside the locales-xx-XX.xml files
when specifying the localization date formats?
Rintze