Limits of binding in the formats manager

[jeremydouglass]

This describes how I understand binding in Format Manager and what I suspect is a fundamental limit that prevents specifying certain correct outputs. I give an example in MLA style.

I've been wresting since I got Bookends with a fairly basic limitation that was hard for me to articulate. I think I've finally figured it out, and I'd love a reality check and perhaps any thoughts on workarounds.

If you edit your own formats in the Formats Manager, Bookends supports five kinds of binding:

• Bind Automatically To Left (just type punctuation with a following space). Prints as long as some term happens later, otherwise drops in favor of the final punctuation mark. (e.g. commas defer to the final period).
• Bind to Both ($foo$). Prints only if both are present.
• Bind to Left (~foo~).
• Bind to Right (|~foo~)
• Bind Never (`foo`). Just print it, always.

The possibilities take a while to figure out, because the most common kind of binding is unnamed, one is called "Quote" (which implies 'just print' to me - totally not the case), and one only exists by combining "Force Bind" with "Break Bind". Of course, there may be other possibilities I'm not thinking about to combine the break with things, but I'm not sure how or why, as the five above should cover all possibilities.

Other people may find the current labeling intuitive. That's fine. I'm describing my process of figuring this out in case other people thinking of binding in the same way I do: what sticks to what?

So we have these binding possibilities, and I'm finally ready to fix something that has nagged me for a long time: the formats as shipped don't degrade gracefully. In a perfect world, every work would have a publisher AND a city AND a year. In my world, some things are self-published or performance art ephemera etc. (no publisher), many things have no city (if the publishing entity is only online), and sometimes the year is unknown - on some historical documents, *very* unknown, and the bibliography isn't the right place to speculate. This probably affects you a lot more if you are in art, literature, history, sociology, anthropology, etc. than if you only deal with recent books and journal articles.

Here's a silly example of correct entries I should be able to create in MLA style, depending on what I enter:

• Cher. Me. New York: BMI, 2090.
• Cher. Me. New York, 2090.
• Cher. Me. BMI, 2090.
• Cher. Me. 2090.
• Cher. Me. New York: BMI.
• Cher. Me. New York.
• Cher. Me. BMI.
• Cher. Me.

These are the results given if you type the available information into an MLA web form such as EasyBib. They are all correct. But I'm beginning to suspect that this set is impossible to define in a Bookends format string. You can fix any error in the list only by creating an error somewhere else. That's because the comma doesn't bind to one entity. It should bind to the (City:Publisher) pair. If the pair returns a result, the comma should print. If not, no comma.

At present, I suspect this is impossible in Bookends. The question is where you want the error. You can print the the comma all the time and bind the colon to both neighbors, which gets the common case of publisher-no-city and the rare case of city-no-publisher right, but adds a weird comma to the common cast of year-only:

• Cher. Me. New York, 2090.
• Cher. Me. BMI, 2090.
• Cher. Me., 2090. ***wrong***

Or you can bind the colon to city and the comma to publisher, which gets the common cases of publisher-no-city and year-only right, but misprints a colon in city-no-publisher:

• Cher. Me. New York: 2090. ***wrong***
• Cher. Me. BMI, 2090.
• Cher. Me., 2090.

Right now, I'm doing the second and proofing my outputs. Here is the string I use right now, which I believe is largely correct:

Code: Select all

a. t. u11. $Trans. $u3*~. ~|f, $ed++. $e, u2$ ed.$, $ Vol. $v$. $u13$ vols.$~ ~l~: ~u~, ~d. u12. p-`.`

Other problems in other media types and styles follow this basic pattern - I finally realized that my 'fixes' were error shuffling. I describe this situation for two reasons.

First, it finally occurred to me today that, with the binding system as given, I may never actually fix it, because my problems are all unfixable. If you are going through this, take a look at your problem, and if it resembles mine just let it be and fix it in post-processing.

Second, if this is the case, I thought it might be worth talking about if there are systematic workarounds, or if there is some very simple extension to the format syntax that might be considered in a future release. I appreciate that making the syntax significantly more complex to handle edge-cases is unappealing, but this seems from my perspective like a pretty fundamental problem. Unless of course MLA style is uniquely baroque and the issue doesn't arise elsewhere.

Any suggestions appreciated.

[Jon]

Hi,

There are two kinds of binding logic: space placement and the ~ forced binding. Quoted text (forced or not) is in fact "just print", but comes in two flavors, $ (which obeys binding rules) and ` (a force quote, which will cause the text in between to be printed regardless of surrounding information).

Bookends does a pretty good job of handling most situations, and the major formats we distribute (such as MLA) are engineered to do that. But of course not all situations are taken into account, and I may have missed something (or made a mistake). So if you have a particular set of possible entries for a Type (e.g Book) your best bet is to enter all of them in one small db and send it to me. I'll tweak the MLA filter if necessary to do what I can.

Jon
Sonny Software

[jeremydouglass]

Jon,

I wasn't implying that Bookends doesn't largely work or claiming it doesn't ship with good defaults. I was offering an example of how binding as defined in Bookends *can never* properly format MLA, or any style that requires binding to a subset of terms. Sorry if that got lost in an overly verbose example above.

I'll send you a sample database mocking this up to play with, but I get the sense you didn't actually read my example or my questions below. To restate:

Cher. Me. New York: BMI, 2090.

I'd like to bind the comma to the city/pub COMBINED, as is standard in MLA style, so that taking out EITHER still prints the comma, but taking out BOTH does not, as follows:

Cher. Me. New York, 2090.
Cher. Me. BMI, 2090.
Cher. Me. 2090.

My point again was that Bookends binds to neighbors only, not parenthetical sets of terms, so it can't do this by definition. It isn't a question of playing with possibilities - it appears formally impossible with the syntax available. Maybe I'm wrong. I'll send you a toy database to play with.

best,
Jeremy

[Jon]

Hi,

I did read your examples, but frankly without concrete data to play with it's often really difficult to say what is and what's not possible. In this case (the city: publisher combination), Bookends will leave in the comma if both publisher and location are empty (it could clean up the ., but there are situations where that combination is legitimate).

Jon
Sonny Software

[jeremydouglass]

To wrap up this thread: Jon generously spent some time working with me on this, and it looks like hte above advice is correct.

You can't bind subsets in Bookends, so no matter how your MLA string is formatted one of three omissions (either city, publisher, or year) will cause a a format error. My personal advice is to use the string suggested above and spot-check for erroneous colons in the rare case that the publisher is missing.

A similar solution applies to any format that requires binding to a subset. Hope this was helpful.