Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Expand number of locator terms #94

rmzelle opened this Issue May 3, 2012 · 4 comments


None yet
2 participants

rmzelle commented May 3, 2012

See http://forums.zotero.org/discussion/14717/universal-locator-type/

In addition to just expanding the number of locator terms, we could also add an empty-string locator type, so that the user can store the label in the locator variable field.

Regardless of the solution chosen, we probably should make an inventory of missing locator types.

Identified so far:
Plays: Act I, scene i, lines 12-23 (or act, scene, verse)
Ancient sources: Book 1, lines 1-8; Book 6, chapters 57‐58
Bibles: Psalm 86:5; 1 Cor. 13:1 New International Version (Book Chapter:Verse, Translation)
Legal: article


See also the discussion at http://xbiblio-devel.2463403.n2.nabble.com/Improving-support-for-locators-td7578007.html


bdarcus commented Jun 7, 2012

Minor issue:

{ "label": "none", "locator": "Act I, scene i, lines 12-23" }

First point is this is easier as just:

{ "locator": "Act I, scene i, lines 12-23" }.

E.g. just make the label key optional.

The second point is more about the substance of the proposal. If I understand right, we have two, completely orthogonal, issues here.

  1. custom locators (what to do about point locator labels we haven't itemized?)
  2. multiple locators

This proposal (as represented in the example above; it's doesn't seem to be formalized as such) attempts to solve both problems at once, so that the upshot is that the second problem requires a free text value.

For sake of argument, why not split these issues, so that you have a point locator defined as a list of key values; something like?

  { "act": "1"},
  { "scene": "3"},
  { "value": "foo 5"}

rmzelle commented Jun 7, 2012

@bdarcus, with regard to making the "label" field optional: yes, I already realized yesterday that that would be a cleaner solution.

With regard to storing hierarchical locators in a structured way: this is obviously preferred from a data perspective, but wouldn't this require a lot of enhancements to CSL, CSL processors and CSL applications? How are we going to deal with the delimiters between these locator elements? Do users have to enter the locator elements in separate fields, or should the CSL processor try to parse the field (and what happens if the parsing fails?). I don't mind revisiting this later, but having a no-label locator value seems like a very effective stopgap measure for CSL 1.0.1.


bdarcus commented Jun 7, 2012

How are processors supposed to deal with this now (with this
proposal)? They simply don't process the value unless there's a
locator type?


rmzelle commented Jun 7, 2012

That's my understanding, yes. @fbennett, that's what you're thinking too, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment