Hi all,
Sorry for the potential thread break — I'm a new member to the list so I
can't reply to this thread in a nice way...
My apologies in advance if this idea has previously been proposed and
decided against. I've only kept up with the list for a short while now.
I'm a developer for Paperpile, a new(ish) reference manager making use of
CSL and citeproc-js.
Personally, I'd love to see CSL move toward widespread support for the
solution that Bibtex has used for years, which is to allow users to
surround words with braces to protect the capitalization as-is. This would
go very far towards giving a user the power to force de-capitalization (or
capitalization) of things that they know should be a certain way in their
bibliography, despite the CSL style and/or the processor's best attempts to
do the right thing.
It seems clear that no matter how smart one is about trying to title-case,
there will always be edge cases where a single item is improperly
capitalized. Without any user-facing way to protect these edge cases, we're
stuck either (a) avoiding title case like the plague in CSL styles and just
using strings as-is from the input, or (b) embracing title case in the
styles and dealing with frustrated users who can't tweak things the way
they want.
Some benefits to a bibtex-like syntax for protecting capitalization would
be:
- It's immediately familiar to anyone who's ever used bibtex.
- It's directly interoperable with existing bibtex data.
- It's simple enough for many users to learn and remember. (I don't think
an HTML syntax would ever have this benefit.)
- It easily generalizes to all variable outputs, not just titles.
(For context, we recently had a user contact us about incorrect
capitalization of journal names in APA style:
https://github.com/citation-style-language/styles/issues/759 which brought
this issue to our attention.)
I think any type of HTML-based syntax would be misdirected toward
capitalization, since the issues of formatting (e.g. italics, superscript)
and capitalization are not one and the same. Formatting is specific to only
non-plain-text outputs, while capitalization is relevant no matter how a
citation is ultimately being displayed.
All that said, maybe there's some obvious problem with this approach, or
maybe it's something that should be left up to each processor to decided.
However, I have a feeling it would be best in the long term to have
something clearly spelled out in a processor-agnostic document to both
improve clarity and aid widespread adoption.
If there's interest, we'd be happy to help implement this in citeproc-js.
greg
On Fri, Nov 15, 2013 at 4:13pm, Aurimas Vinckevicius wrote:
>Clearly, string formatting (mostly in titles) is necessary and is getting
>implemented whether CSL specifies it or not. IMO HTML (or XML, which would
>probably be more work for everyone) is the most elegant and broadly
supported
>approach.
>If CSL really wants to remain format-agnostic in this regard, then it
could just
>specify that substrings can be marked (with possible nesting) for various
>formatting (italics, superscript, forced title-casing, etc.) and leave the
language
>of the formatting up to the citeproc developers. CSL can then go on to
specify
>how such substrings are handled when producing citations.
On Thu, Nov 14, 2013 at 9:52 PM, Bruce D'Arcus <[hidden email]> wrote:
>
> I haven't looked at this issue, but putting html in json files feels
> really wrong as a general proposition.
>
> On Thu, Nov 14, 2013 at 10:02 PM, Rintze Zelle <[hidden email]> wrote:
> > So far the CSL spec is rather format-agnostic when it comes to input.
It's
> > one of the reasons why citeproc-js's support for inline rich text
formatting
> > of titles (http://www.zotero.org/support/kb/rich_text_bibliography)
isn't
> > included in the spec.
> >
> > I see the use of what you're proposing, but it is rather HTML-oriented.
Are
> > we comfortable including something like this in the spec, or would it be
> > better to have a separate (sub)document that focuses on CSL input (which
> > could also be used to describe the CSL JSON data model)?
> >
> > Rintze
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
xbiblio-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel