adding schema changes

Can people please take a look at these changes (am tired am may well
have made some dumb mistake!)?------------------------------------------------------------------------
r1066 | bdarcus | 2009-07-12 17:05:52 -0400 (Sun, 12 Jul 2009) | 1 line

adding date and quote localization options

r1063 | bdarcus | 2009-07-12 16:32:41 -0400 (Sun, 12 Jul 2009) | 1 line

added cs:name-part child to cs:name

r1054 | bdarcus | 2009-07-10 17:02:14 -0400 (Fri, 10 Jul 2009) | 1 line

removed font-family formatting attribute

Oh, on the terms/locales stuff, for now the changes are backward
compatible. If these work, we can look at changing the cs:terms root
to cs:locales.

Bruce

Just one :). Typo alert for: attribute name {“puncuation-in-quote”},
attribute value { xsd:boolean } --> (punc-t-uation)

But I don’t get the date-locale support. You can only switch around
the day and month? What happens if locales use yyyy-mm-dd (e.g.
ftp://ftp.software.ibm.com/software/globalization/locales/Sweden-Swedish_Date.pdf)
with year first? I’d expected something more extensive and flexible,
e.g. (using the Swedish example):

Full Date Format in Native Language: tisdag 10 april 1998
Long Date Format in Native Language: 10 april 1998
Common Date Format in Native Language: 1998-04-10
Short Date Format in Native Language: 98-04-10

In locales-sv-SE.xml:

Måndag
Tisdag
Onsdag
Torsdag
Fredag
Lördag
Söndag

Styles could then just call a standard date-format (e.g. just ), and override date formats via the locales-element in
the style. I can even imagine that one could use to just show year-month (e.g. 1998-04); the parts
attribute would provide an unordered subset of date-parts to render.
Small elaborations on my suggestion: I really would like a way to
define delimiters between date-parts (IMHO it’s the only way
incomplete dates, e.g. dates lacking day numbers, can be correctly
rendered). Furthermore, I understand that showing the week-day will
require some logic to calculate the weekday matching a certain date.
Don’t know if that’s worth the trouble. Finally, I’ll admit it’s all
terribly backwards-incompatible, but I don’t see how we can come to
full fledged date support otherwise.

Rintze

Frank suggested we could still allow date formats to be overruled by
the existing way to specify date formats: “A date singleton would call
on the locale def, but you could allow a full date span, which would
just do its own thing, the way things work now”. Although styles doing
that wouldn’t benefit from date-localization, it seems to be backwards
compatible.

Rintze

Can people please take a look at these changes (am tired am may well
have made some dumb mistake!)?

Just one :). Typo alert for: attribute name {“puncuation-in-quote”},
attribute value { xsd:boolean } --> (punc-t-uation)

Thanks.

But I don’t get the date-locale support. You can only switch around
the day and month? What happens if locales use yyyy-mm-dd (e.g.
ftp://ftp.software.ibm.com/software/globalization/locales/Sweden-Swedish_Date.pdf)
with year first? I’d expected something more extensive and flexible,
e.g. (using the Swedish example):

Well, it’s certainly my intention to allow this. I was just tired of
talking about it, and thought we ought to start implementing.

Full Date Format in Native Language: tisdag 10 april 1998
Long Date Format in Native Language: 10 april 1998
Common Date Format in Native Language: 1998-04-10
Short Date Format in Native Language: 98-04-10

In locales-sv-SE.xml:

Måndag
Tisdag
Onsdag
Torsdag
Fredag
Lördag
Söndag

Styles could then just call a standard date-format (e.g. just ), and override date formats via the locales-element in
the style. I can even imagine that one could use to just show year-month (e.g. 1998-04); the parts
attribute would provide an unordered subset of date-parts to render.
Small elaborations on my suggestion: I really would like a way to
define delimiters between date-parts (IMHO it’s the only way
incomplete dates, e.g. dates lacking day numbers, can be correctly
rendered).

I’ll look at this later.

Furthermore, I understand that showing the week-day will
require some logic to calculate the weekday matching a certain date.
Don’t know if that’s worth the trouble.

It’s not :wink:

Finally, I’ll admit it’s all terribly backwards-incompatible, but I don’t see how we can come to
full fledged date support otherwise.

Right; this was a stupid design decision in CSL, and I see no way to
reasonably fix it without breaking things.

Bruce

First, I don’t know what a singleton is.

Second, my main goal in this set of changes was to align date and name
formatting and localization. I don’t mind if we have to break things
to get this, because it’s pretty critical.

Bruce

Frank’s singleton:

(layout is retrieved from locale)

Frank’s full date span:

(current setup)

If these things can co-exist, backward compatibility shouldn’t be an issue.

Rintze

Frank’s singleton:

(layout is retrieved from locale)

Frank’s full date span:

(current setup)

If these things can co-exist, backward compatibility shouldn’t be an
issue.

It would not be consistent with names.

Finally, I’ll admit it’s all
terribly backwards-incompatible, but I don’t see how we can come to
full fledged date support otherwise.

Frank suggested we could still allow date formats to be overruled by
the existing way to specify date formats: “A date singleton would call
on the locale def, but you could allow a full date span, which would
just do its own thing, the way things work now”. Although styles doing
that wouldn’t benefit from date-localization, it seems to be backwards
compatible.

First, I don’t know what a singleton is.

Second, my main goal in this set of changes was to align date and name
formatting and localization. I don’t mind if we have to break things
to get this, because it’s pretty critical.

I’m kind of confused. What would it mean to align formatting and
localization for dates and names?

Second, my main goal in this set of changes was to align date and name
formatting and localization. I don’t mind if we have to break things
to get this, because it’s pretty critical.

I’m kind of confused. What would it mean to align formatting and
localization for dates and names?

Am talking more meta than that; that formatting of the parts are
independent of ordering of the parts, which is in turn
locale-specific.

The problem of the current date handling is that it collapses
formatting and ordering, and so breaks the goals of styles being
locale-independent.

Bruce

Can people please take a look at these changes (am tired am may well
have made some dumb mistake!)?

Just one :). Typo alert for: attribute name {“puncuation-in-quote”},
attribute value { xsd:boolean } --> (punc-t-uation)

But I don’t get the date-locale support. You can only switch around
the day and month? What happens if locales use yyyy-mm-dd (e.g.
ftp://ftp.software.ibm.com/software/globalization/locales/Sweden-Swedish_Date.pdf)
with year first?

Add another option: maybe “date-full-order” (“year-first” and “year-last”)?

I’d expected something more extensive and flexible,
e.g. (using the Swedish example):

Full Date Format in Native Language: tisdag 10 april 1998
Long Date Format in Native Language: 10 april 1998
Common Date Format in Native Language: 1998-04-10
Short Date Format in Native Language: 98-04-10

Do we have any evidence all of this is needed?

In locales-sv-SE.xml:

Måndag
Tisdag
Onsdag
Torsdag
Fredag
Lördag
Söndag

As I suggested; this is serious overkill.

Styles could then just call a standard date-format (e.g. just ), and override date formats via the locales-element in
the style. I can even imagine that one could use to just show year-month (e.g. 1998-04); the parts
attribute would provide an unordered subset of date-parts to render.
Small elaborations on my suggestion: I really would like a way to
define delimiters between date-parts (IMHO it’s the only way
incomplete dates, e.g. dates lacking day numbers, can be correctly
rendered).

Bruce

But formatting is also locale-specific:


Japan:
yyyy年mm月dd日 (affixes, leading zeros)

Germany:
d.m.(yy)yy or d. month (yy)yy (periods/spaces as delimiters, no leading zeros)

France:
dd/mm/yyyy (delimiters, leading zeros)

Rintze

Can people please take a look at these changes (am tired am may well
have made some dumb mistake!)?


r1066 | bdarcus | 2009-07-12 17:05:52 -0400 (Sun, 12 Jul 2009) | 1 line

adding date and quote localization options

All that’s needed for quote localization is to set those four items
(open-quote, close-quote, open-single-quote, close-single-quote) as
ordinary terms. No need to cast them as options.

Yeah, that’s what I meant to do. As I said; was tired.

Bruce

OK; fixed. However, I did keep the punctuation config as an option.

Bruce

Can people please take a look at these changes (am tired am may well
have made some dumb mistake!)?


r1066 | bdarcus | 2009-07-12 17:05:52 -0400 (Sun, 12 Jul 2009) | 1 line

adding date and quote localization options

All that’s needed for quote localization is to set those four items
(open-quote, close-quote, open-single-quote, close-single-quote) as
ordinary terms. No need to cast them as options.

Yeah, that’s what I meant to do. As I said; was tired.

OK; fixed. However, I did keep the punctuation config as an option.

Perfect! Thanks.

I’m kind of confused. What would it mean to align formatting and
localization for dates and names?

Am talking more meta than that; that formatting of the parts are
independent of ordering of the parts, which is in turn
locale-specific.

But formatting is also locale-specific:

http://en.wikipedia.org/wiki/Calendar_date#Usage_issues
Japan:
yyyy年mm月dd日 (affixes, leading zeros)

Germany:
d.m.(yy)yy or d. month (yy)yy (periods/spaces as delimiters, no leading zeros)

France:
dd/mm/yyyy (delimiters, leading zeros)

Rintze raises an important point. The justification for filling out
localization with dates support is to allow one unifom style to
support multiple languages. A few non-English styles have already
appeared in the repository, and the test for an extended localization
scheme would be whether it would allow them to be merged back into the
core styles from which they are derived. Otherwise there doesn’t seem
to be any gain from the extral work involved.

One example would be chicago-author-date.csl and
chicago-author-date_de.csl (zotero.org not available as I write this,
so can’t offer a link). As Rintze’s list above suggests, the German
version of Chicago Author-Date uses different punctuation from
English. It seems like the obvious way to give the locale that level
of control over date formatting is to move the date/date code blocks
currently located in the style body into the locale, and then call the
locale-defined date configurations from the style body with a
"singleton" like .

Frank