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 5:49 PM, Bruce D'Arcus <[email protected]> wrote:
> On Wed, Nov 20, 2013 at 6:42 PM, Frank Bennett <[email protected]>
> wrote:
>
> ....
>
> > 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
> > (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.
>
> That's right. Not only represented, though, but also easily UI-ified
> (think, say, a client like zotero with a context menu that allows one
> to select how to treat particular sub-field text).
>
> Any discussion of changes to this particular solution should probably
> consider the goals, too.
>
> Bruce
>
> > 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
>
>
> ------------------------------------------------------------------------------
> 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
>
--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University
------------------------------------------------------------------------------
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
