Style duplication

Not sure how they are implemented at the moment, but this is a good
reference on best practices for choosing quite characters:

http://www.dwheeler.com/essays/quotes-in-html.html

–J

Just tried that and it seems to work a treat in html and word at
least! I think we have a solution!

sorry to sound like a broken record, but the suffix solution won’t
work in this case:

because in some cases the title may be enclosed in quotes, but in
others it would be in italics:

Gomery, The Hollywood Studio System.

but:

Jacob, “Eventful Transformations.”

where full note citations are:

Douglas Gomery, The Hollywood Studio System (London: British Film
Institute, 2005).

Wilson Chacko Jacob, “Eventful Transformations: Al-Futuwwa between
History and the Everyday” Comparative Studies in Society and History
49, no. 3 (2007): 689-712.

Elena> Thanks,

Julian Onions wrote:

I don’t think the locales will be a good solution. The journal in
question says that that is the house style. So if you wish to submit an
article to the journal in its specified format, that’s how it should
look. So typically people will want to select that style and submit the
paper, not want to go changing locales and stuff.

Perhaps there ought to be a generic option for quoting style such that
it can be set for the style irrespective of locale?

Of course, in essence, this is a locale-specific journal style (as most
are), which might suggest the style itself ought to have the appropriate
language value set (rather than “en”)?

I tried putting ` and ’ as prefix and suffix, but it doesn’t look very
good. I;m not sure what is used in word but its not the regular ascii
single quotes. Maybe there is an HTML or Unicode character that is better?

As I said, I don’t think this is a good solution, because it conflicts
with a decision we made awhile ago.

Also, do not use entities in CSL please. As David says in that article,
it’s fine to use the unicode code points, though you can also just use
the unicode characters directly (since you shouldn’t be using non-curly
quotes).

Bruce

Elena,

Elena Razlogova wrote:

sorry to sound like a broken record, but the suffix solution won’t
work in this case:

because in some cases the title may be enclosed in quotes, but in
others it would be in italics:

I’m not sure I’m following this thread. Can you explain your issue again?

I know Julian is simply noting that he wants to be able to set British
rules. So he’s essentially wanting to turn off quoting, and do it manually.

I think you’re pointing out what is basically a bug in Zotero, but am
not entirely sure.

Bruce

Not sure how they are implemented at the moment, but this is a good
reference on best practices for choosing quite characters:

http://www.dwheeler.com/essays/quotes-in-html.html

–J

Just tried that and it seems to work a treat in html and word at
least! I think we have a solution!

sorry to sound like a broken record, but the suffix solution won’t
work in this case:

sorry this should really be:

where the macro defines whether the title needs quotes or not

I’m not sure I’m following this thread. Can you explain your issue
again?

I know Julian is simply noting that he wants to be able to set British
rules. So he’s essentially wanting to turn off quoting, and do it
manually.

I think you’re pointing out what is basically a bug in Zotero, but am
not entirely sure.

Yes, Simon’s code arranges quotes and commas/periods correctly
between adjacent variables, but not at the end of the entire
citation, so if the citation ends in a quotation mark, the period
follows the quotation mark instead of preceding it. This is correct
for the British style, but not for the US.> Bruce

I think you’re pointing out what is basically a bug in Zotero, but am
not entirely sure.

Yes, Simon’s code arranges quotes and commas/periods correctly
between adjacent variables, but not at the end of the entire
citation, so if the citation ends in a quotation mark, the period
follows the quotation mark instead of preceding it. This is correct
for the British style, but not for the US.

P.S. I do think this problem can only be solved by writing some sort
of condition in code, not manually. But perhaps this problem is too
minor to consider a solution. Elena>> Bruce

Yes, that’s a Zotero bug. It should be fixed sooner or later,
depending on how much free time I have over the next week.

Simon

Where can one set this language value? xml:lang is the language used
in contents and attribute values, not the language in which the
document should be formatted by default. If an appropriate attribute
for default locale existed, and Zotero used the style-specific default
locale by default, it seems like it would resolve this case, since the
style should be formatted in en-GB with UK-style quotes by default.
Furthermore, Britons submitting to both US and UK journals wouldn’t
have to know the appropriate locale for each journal and switch their
global locale appropriately.

Simon Kornblith wrote:

Where can one set this language value? xml:lang is the language used
in contents and attribute values, not the language in which the
document should be formatted by default. If an appropriate attribute
for default locale existed, and Zotero used the style-specific default
locale by default, it seems like it would resolve this case, since the
style should be formatted in en-GB with UK-style quotes by default.

So shall we add an optional “default-locale” attribute (or element)?

Furthermore, Britons submitting to both US and UK journals wouldn’t
have to know the appropriate locale for each journal and switch their
global locale appropriately.

This isn’t an uncommon situation (a number of the journals in my field,
for example, publish out of the UK, including the one I’m preparing a
manuscript for ATM), so it’d be nice to resolve.

On the other hand, I don’t have as much of a problem as Bruce does
with adding quotes to the prefix and suffix, since it seems unlikely
anyone would want to use a journal-specific format with US-style quotes.

I just think we should be consistent.

And we’re only now dealing with a binary option (British vs. US). What
happens if/when it gets more complex?

Bruce

If a Frenchman uses the Nature style, it’s probably safe to assume
he wants UK English locale terms and quotes, too. As long as we
provide the opportunity to override the default locale with the global
locale, localized variants of, e.g., APA should be available if the
author decides to use them.

Simon

Simon Kornblith wrote:> On Nov 26, 2007, at 1:10 PM, Bruce D’Arcus wrote:

And we’re only now dealing with a binary option (British vs. US). What
happens if/when it gets more complex?

If a Frenchman uses the Nature style, it’s probably safe to assume
he wants UK English locale terms and quotes, too.

Right, but that’s the easy case.

I’m talking about more generic styles where a French user may well want
it adapted to their locale.

So what – if anything – are we doing about this in CSL? Shall we add a
default-locale attribute?

Bruce

Right, which I also addressed: we can provide a simple popup menu to
switch from the style default locale to the global locale, which would
be French on a French system, or to any other locale the user might
desire.

Simon

Simon Kornblith wrote:

I’m talking about more generic styles where a French user may well
want it adapted to their locale.

Right, which I also addressed: we can provide a simple popup menu to
switch from the style default locale to the global locale, which would
be French on a French system, or to any other locale the user might
desire.

Simon – I have every confidence you know what you’re doing, and I’m not
challenging you on that. So we’re talking past each other I think.

What I really want to know is: WHAT TO DO on the CSL end of things?

So to repeat for the third time: shall we add an optional
"default-locale" attribute to the schema? You suggested it earlier, but
I wasn’t clear if you were presenting it as a firm proposal.

Bruce

Yes. Unless there are complaints, it seems to me like this is the best
solution.

Simon

Simon Kornblith wrote:

Simon – I have every confidence you know what you’re doing, and I’m
not
challenging you on that. So we’re talking past each other I think.

What I really want to know is: WHAT TO DO on the CSL end of things?

So to repeat for the third time: shall we add an optional
"default-locale" attribute to the schema? You suggested it earlier,
but
I wasn’t clear if you were presenting it as a firm proposal.

Yes. Unless there are complaints, it seems to me like this is the best
solution.

Simon

OK, thanks :slight_smile:

I just committed this addition:

   ## Refers to the default locale for the style; should generally
   ## be set for any academic journal, since it can be used to ensure
   ## proper quote formatting and such.
   attribute default-locale { xsd:language }?,

OK with everyone?

Bruce

I’m not sure if it’s relevant to the immediate discussion (or maybe already
included in it), but remember that with in-line citations, a citation’s
ending punctuation may depend on where the citation sits in a sentence.

For more criticisms of Meyer, “Galileo’s Basin,” see Shea, “Galileo on the
Tides.”

or, in UK-style,

For more criticisms of Meyer, “Galileo’s Basin”, see Shea, “Galileo on the
Tides”.

– John

Picking this back up… Sorry for the length, but hoping to get these
issues resolved.

Simon Kornblith wrote:

Journal of Primitive Zoology http://www.zotero.org/styles/mla 2007-09-06T06:36:07+00:00

This seems like the most reasonable way of dealing with a journal that
takes plain APA style. It’s probably not the most reasonable way of
dealing with a set of journals with the same style (e.g., PLoS Biology
vs. PLoS Medicine, or the various Springer styles), which would do
better with a single CSL that simply contained all of their names.
But, in the interest of simplicity, I think that this would work fine.

So can I get some votes on this?

The change would involve adding an optional “source” attribute on the
root. Where present, a processor would instead load the content
(everything but the info element) from the style identified with that URI.

As I mentioned previously, this is a trivial change with big
implications, so I want to make sure everyone’s comfortable with it.

A “source” attribute on the root could work, though the Atom spec
suggests a few other possibilities:

  • Use “src” for the root attribute, since “source” has a different
    meaning in Atom (albeit as an element).
  • Use an empty element – “atom:content MAY have a
    ’src’ attribute… If the ‘src’ attribute is present, atom:content MUST
    be empty. Atom Processors MAY use the IRI to retrieve the content and
    MAY choose to ignore remote content or to present it in a different
    manner than local content.” In our case, the element would
    essentially be implicit otherwise.
  • Use – “atom:entry elements that
    contain no child atom:content element MUST contain at least one
    atom:link element with a rel attribute value of ‘alternate’.”

Of these, would probably transpose
the best into an Atom-based repository index. (This is all a little
messy, since, from the perspective of the metadata, in a CSL
file is essentially the style definitions and in the feed
entry would either contain a sample of the style output or be empty (if

is used for the samples), with linking to the CSL file. So the quote above doesn't quite justify using rel="alternate" to point to the source style from the feed, but given that it still more or less "identifies an alternate version of the resource described by the containing element," I'm fine with it.)

To address an earlier question from Bruce:

Example:

Style B simply borrows Style A wholesale.

Two years later, Style B changes their style with some slight
modifications, in essence creating a custom style specific to the journal.

What happens to the styles? To the user who depends on Style B?

Journal edits Style B, removing [whatever we choose as the indicator of
external content] and adding regular CSL content. Style B’s timestamp is
updated, so when the CSL client checks for an update, it sees that
there’s no longer [an external content indicator] and uses the embedded
content instead.

(When there is [an external content indicator], the CSL client will need
to grab a copy of Style A, cache it, and check for updates to it in
addition to checking for updates to Style B. Style A should not appear
as installed in the client.)

Dan Stillman wrote:

A “source” attribute on the root could work, though the Atom spec
suggests a few other possibilities:

  • Use “src” for the root attribute, since “source” has a different
    meaning in Atom (albeit as an element).
  • Use an empty element – “atom:content MAY have a
    ’src’ attribute… If the ‘src’ attribute is present, atom:content MUST
    be empty. Atom Processors MAY use the IRI to retrieve the content and
    MAY choose to ignore remote content or to present it in a different
    manner than local content.” In our case, the element would
    essentially be implicit otherwise.
  • Use – “atom:entry elements that
    contain no child atom:content element MUST contain at least one
    atom:link element with a rel attribute value of ‘alternate’.”

I worry about the flexibility of Atom in this case. We need to make a
decision here: do we stick as closely as possible to the Atom spec, or
do we focus on a clear, dedicated, grammar that can be easily
controlled, validated, etc. (and which can also be easily mapped to Atom)?

With these suggestions, I’m leaning towards the second direction of course.

Of these, would probably transpose
the best into an Atom-based repository index. (This is all a little
messy, since, from the perspective of the metadata, in a CSL
file is essentially the style definitions and in the feed
entry would either contain a sample of the style output or be empty (if

is used for the samples), with linking to the CSL file. So the quote above doesn't quite justify using rel="alternate" to point to the source style from the feed, but given that it still more or less "identifies an alternate version of the resource described by the containing element," I'm fine with it.)

The CSL info object really ought to correspond to an atom:entry.

To address an earlier question from Bruce:

Example:

Style B simply borrows Style A wholesale.

Two years later, Style B changes their style with some slight
modifications, in essence creating a custom style specific to the journal.

What happens to the styles? To the user who depends on Style B?

Journal edits Style B, removing [whatever we choose as the indicator of
external content] and adding regular CSL content. Style B’s timestamp is
updated, so when the CSL client checks for an update, it sees that
there’s no longer [an external content indicator] and uses the embedded
content instead.

(When there is [an external content indicator], the CSL client will need
to grab a copy of Style A, cache it, and check for updates to it in
addition to checking for updates to Style B. Style A should not appear
as installed in the client.)

Right, with the source link, this works.

Essentially, I was trying to suggest that each style a user might want
to “see” should have a unique ID/URI and separate files (rather than,
for example, include multiple titles in a single CSL file).

Dan Stillman wrote:

A “source” attribute on the root could work, though the Atom spec
suggests a few other possibilities:

  • Use “src” for the root attribute, since “source” has a different
    meaning in Atom (albeit as an element).
  • Use an empty element – “atom:content MAY have a
    ’src’ attribute… If the ‘src’ attribute is present, atom:content MUST
    be empty. Atom Processors MAY use the IRI to retrieve the content and
    MAY choose to ignore remote content or to present it in a different
    manner than local content.” In our case, the element would
    essentially be implicit otherwise.
  • Use – “atom:entry elements that
    contain no child atom:content element MUST contain at least one
    atom:link element with a rel attribute value of ‘alternate’.”

I worry about the flexibility of Atom in this case. We need to make a
decision here: do we stick as closely as possible to the Atom spec, or
do we focus on a clear, dedicated, grammar that can be easily
controlled, validated, etc. (and which can also be easily mapped to Atom)?

With these suggestions, I’m leaning towards the second direction of course.

That’s fine. I was going mostly on your earlier comment that the
"content model for CSL metadata be the same as Atom." But we can
certainly choose a clearer grammar, and how we map them to Atom doesn’t
really matter as long as we don’t expect standard readers to do anything
special with them.

In any case, I rescind my rel=“alternate” recommendation for linking to
source styles, since it seems most blogs use that to point to the
permalink of the post, and for us that means the location of the current
style itself (not the source style). In fact, in Atom, rel="alternate"
is the default when a ‘rel’ isn’t provided, so both the feed entry and
should just have an element like pointing to the style URL.

For the source style, some sort of element might still be best,
since it’s a standard mechanism. If we’re not content with the five
provided ‘rel’ values in the spec (or any approved extensions), we could
use an arbitrary value like ‘source’ or ‘origin’ and transform that to a
fully qualified URI like http://purl.org/net/xbiblio/csl/relation/source
in the feed.

OK, Dan, am updating the metadata section of the schema. I’ve checked in
the enhanced cs:source element based on your suggestion.

But I have a couple questions on the rest …

Dan Stillman wrote:

In any case, I rescind my rel=“alternate” recommendation for linking to
source styles, since it seems most blogs use that to point to the
permalink of the post, and for us that means the location of the current
style itself (not the source style). In fact, in Atom, rel="alternate"
is the default when a ‘rel’ isn’t provided, so both the feed entry and
should just have an element like pointing to the style URL.

For the source style, some sort of element might still be best,
since it’s a standard mechanism. If we’re not content with the five
provided ‘rel’ values in the spec (or any approved extensions), we could
use an arbitrary value like ‘source’ or ‘origin’ and transform that to a
fully qualified URI like http://purl.org/net/xbiblio/csl/relation/source
in the feed.

I’ve basically copy-and-pasted the Atom schema definition, and am now
adapting it to CSL. Here’s where I’m at:

info-link =
element cs:link {
attribute href { xsd:anyURI },
attribute rel { atomNCName | atomUri }?,
attribute type { atomMediaType }?,
attribute hreflang { xsd:language }?,
attribute title { text }?,
attribute length { text }?,
string
}

So:

a) should we constrain the rel values, and if so, what should they be?
b) if we need “type” shall we constrain the values, and if so, what
should they be?
c) in general, anything else we can remove?

Bruce