Comments (7)
Ok, I can see why. Let's completely determine the desired behaviour.
The reason why that is happening is that CSL in general can prescribe (separately) complex sorting criteria for both grouped citations and bibliographic indices. (It is now prevailing upon the custom options).
To me, it'd make sense that by default sorting is performed using the criteria given by the CSL style, and that could be overwritten by a custom option that can take some simple values. Say, "author" (by last name of first author), "label" (by citation number, din code, other keys), "appearance" (no sorting at all).
Should we be able to specify more complex sorting behaviour? (e.g. lists of sorting keys)
Do any other criteria come to mind?
from asciidoctor-bibliography.
@paolobrasolin agree that we should fully specify the behavior.
These should be good enough?
- author (last name of first (author or editor))
- label ([1] or [aicpa], etc)
- appearance (order of appearance in document)
- title
- date (year / month / day)
- publisher
- institution
- shorthand ?
- type
from asciidoctor-bibliography.
I had an idea; I wrote a stub for a general sorting mechanism in the branch sorting
. You can find a sample use in the standard/sample-deafult.adoc
sample.
Here is my reasoning. If we implement custom-named sorting styles, we must also make assumptions about how the CSL styles are structured: while the variables are defined by the CSL spec, what we're really interested in is macros. Those define how pieces of info are rendered and therefore they also are the most relevant for sorting. While their naming is usually pretty reasonable, it's also completely arbitrary. This means that when someone is using a style that has macros named with a different convention than our assumptions, the sorting can and will break. What's worst is that the user has no way to fix that except writing custom code.
If we make no assumptions instead, I think we have an alternative solution. The idea is to let the user specify the sorting keys with a short YAML string. Here are some examples:
:bibliography-sort: macro: author
:bibliography-sort: { macro: author, sort: descending }
:bibliography-sort: [{ macro: author, sort: descending }, { variable: title, sort: ascending}]
While this is a bit more verbose, we have multiple advantages:
- no magic hardcoded stuff
- much simpler implementation
- user has full control: both keys and variables, explicitly stated, single or multiple sorting keys, all CSL options are available (only the trivial ones are shown above)
Since variables and macros usually have reasonable names this does not necessarily require knowledge of the CSL style itself. And if the user is trying to override the sorting specified by the style, she's probably savvy enough to recover the macro names from the Visual CSL Editor (we should write a note about that in the manual).
It seems to me that the advantages greatly outweight the flaws of this approach.
What do you think? @ronaldtse
from asciidoctor-bibliography.
This is indeed a really good idea. The less magic we do the more predicatable the behavior.
Let's go for it. Thanks!
from asciidoctor-bibliography.
Implemented and documented in branch sort-option.
from asciidoctor-bibliography.
Ready to close as #35 is merged?
from asciidoctor-bibliography.
Ready. Closing.
from asciidoctor-bibliography.
Related Issues (20)
- Bug with custom attributes when translating to DocBook HOT 3
- Question: own styles HOT 1
- :bibliography-database: not set via asciidoctor-epub3 for included documents HOT 6
- Bib entry with identical author and year HOT 18
- Minor APA format issue HOT 4
- Converting directly with Ruby HOT 2
- Variable interpolation breaks include
- anomalies when using Asciidoctor's ifeval::[] and asciidoctor-bibliography HOT 3
- Errors with asciidoctor-pdf HOT 2
- Numbered bibliography
- Comparison with asciidoc-bib and asciidoctor-bibtex
- A problem building Nokogiri, when installing on Windows HOT 7
- Migrate to GitHub Actions from Travis
- Change default branch to main HOT 1
- Asciidoc-bibliography messes with section levels after include
- Feature request: Styling per bibliography
- Citations get parsed within inline source code environment HOT 2
- Multi-Citation of more than two keys not working HOT 5
- [enhancement] nocite macro for bibliography entry without expicit citation HOT 1
- Incompatibility with asciidoctor version >= 2.0 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asciidoctor-bibliography.