If { } are only adopted from BibTeX for preserving capitalization (though
we still have an issue of how to indicate forced capitalization, i.e. CMoS
rule 3) then I don't have much of a problem with this. My only nit would be
mixing HTML (italics, bold, etc.) and BibTeX (capitalization) for markup
(and of course there would need to be a way to escape curly braces). If, on
the other hand, this will eventually lead to adoption of BibTeX syntax for
text formatting, then I would have to say that BibTeX syntax is far far
from straightforward. My biggest issue (which I am still lost in) is the
way capitalization is treated within different levels of brace nesting. How
do I mark up capitalization within, e.g., \textit{ } fragment?
Excerpt from "Tame the Beast" (
http://tug.ctan.org/info/bibtex/tamethebeast/ttb_en.pdf):
> the second transformation applied to a title is to be turned to lower case
> (except the first character).
> The function named change.case$ does this job. But it only applies to
> letters that are
> a brace depth 0, except within a special character. In a special
> character, brace depth is always
> 0, and letters are switched to lower case, except LATEX commands, that are
> left unmodified.
Imagine explaining that to someone who's never actually used BibTeX...
But as I say above, perhaps it makes more sense to allow each processor to
define the syntax of the markup. If a processor was to be written for
LaTeX, then it would probably make sense for it to use full BibTeX syntax
instead of a mix of HTML and BibTeX.
Just my 2 cents.
Aurimas
On Wed, Nov 20, 2013 at 3:00 PM, 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
>
> 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
