Thanks Sebastian for summarizing — it's very helpful to understand more of
the decision-making behind the current state of things.
It's also interesting to hear that citeproc-js already supports this kind
of functionality, albeit with a different syntax. Cool!
Perhaps I came across a bit too evangelical on the Bibtex-brace approach. I
wouldn't ever argue for widespread support of anything more than the braces
to protect caps. Most other parts of LaTeX syntax, as Aurimas mentioned,
are far from ideal. :) And we're not against a different approach if it's
widely agreed upon.
Anyhow, this is definitely an edge case, and any movement toward a
documented solution would benefit greatly from widespread adoption and
feedback from other programs. But this is definitely on our minds, and I'm
encouraged by the possibility that supporting a single syntax within fields
could serve both our bibtex and CSL users equally well.
--greg
Message: 4
Date: Wed, 20 Nov 2013 19:43:06 -0700
From: Sebastian Karcher <[email protected]>
Subject: Re: [xbiblio-devel] title casing skip words
To: development discussion for xbiblio
<[email protected]>
Message-ID:
<CAOSYSD7rxFuBDXPiwE+Hhzmu7F=7jfw9qatksfxkutgtqeq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Just to restate our current approach to this so that we're all on the same
page:
- The recommendation is to store all titles in sentence case. Where
sentence case is required, we just leave them alone (we never use
text-case="sentence" in CSL styles).
- Where title case is required, items can be title-cased correctly in
almost all cases (the "almost" part is what Aurimas wants to solve with
this). So anything we implement will mean a _lot_ less mark-up than bibtex,
where you have to protect every proper name etc. We only need no-casing
exceptions for rare cases like two word species names in English titles
where automatic title casing fails.
- Title casing can be turned of for non-English items using the language
variable (http://citationstyles.org/downloads/specification.html#id87 )
- So far we've not been using title case much for container-titles,
especially of periodicals, even where required for reasons I explain here:
https://github.com/citation-style-language/styles/issues/759#issuecomment-28864718
.
Ss I say in that comment, while I'm not without hesitation about
this, I
think we should reverse what was always an informal and
not-strictly-enforced policy and generally apply title case to container
titles where it is required, though in most cases I don't think it's
particularly urgent to implement - but Rintze and I will be accepting
pull-requests (or appreciate commits from those with direct access) to that
extent.
With all that said, I think we should find a way to do this, but it's going
to be a lot less heavy-handed than the BibTeX approach and I think that's
very good.
I don't have strong views on the implementation side, except that I'd like
to keep it uniform across implementations if it's at all possible to agree,
so that data exchange becomes less of a mess.
Best,
Sebastian
On Wed, Nov 20, 2013 at 6:44 PM, Frank Bennett <[email protected]>wrote:
> On Thu, Nov 21, 2013 at 8:42 AM, Frank Bennett <[email protected]>
> wrote:
> > On Thu, Nov 21, 2013 at 6:00 AM, Gregory Jordan <[email protected]>
> wrote:
> >> 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
> >
> > Some processor-specific syntax for this currently coded into citeproc-js:
> >
> > <span class="nocase">qwerty</span>
> >
> > The "nocase" form has the effect of squiggly braces in BibTeX (as I
> > understand it): it prevents changes to the case of the enclosed text
> > when title case or text case are applied to the field. The idea was
>
> (Oops, sorry, typo: I should have written "when title case or sentence
> case are applied to the field".)
>
> > (and I guess I would say is) to use a markup syntax that can be easily
> > represented in a UI without additional levels of external parsing by
> > the client. As far as I know the syntax isn't supported in the UI of
> > any clients out there, though, and it hasn't seen much use for the
> > obvious-enough reason that it's quite an awkward thing to type, and
> > distracting when displayed verbatim.
> >
> > It should be a simple thing to add a spec line to the parser that
> > applies the same methods to squiggly-brace-enclosed text. Backslash
> > escaping should just work, without additional coding.
> >
> > in citeproc-js, mixing "plain text" and "html" approaches isn't
> > particularly a problem, but smooth operation with other tools might
> > require greater consistency. It would be good to have input from other
> > processor developers and consumers of CSL; and in the interest of data
> > exchange, it would be good to have a description of preferred markup
> > set in an adjunct to the CSL specification before making further
> > changes.
> >
> >
> >>
> >> 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
> >>
>
------------------------------------------------------------------------------
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
