Option to relax dataonly setting for related entries about biblatex

[plk]

We can't just not set skiplab on related entries because this would make them be considered for extra* generation and this causes all sorts of mess if the entries are also directly cited.

Looking at the code for this, the generation of uniquename and uniquelist information is skipped if skiplab is set. I am not sure why I did this as I don't think it's necessary - it can't hurt to always generate this as it doesn't depend on labels. So, I removed this conditional and now your example works ... you can pull the dev branch or get the latest 1.4 dev binaries from SF. This needs the biblatex 2.4 dev release from SF also.

[aboruvka]

Looks good. Thanks. I can't think of any cases where this change would hurt, either. If you come across any, please don't hesitate to revert back to the old code. I'll hold off on posting any solution at TeX.SE until 2.4/1.4 get uploaded to CTAN.

[aboruvka]

Considering this problem a little more I could see where generating the uniquename/list counters even if skiplab=true would be problematic. dataonly entries would presumably never be cited directly. Dropping the citation label edits in the above document for example, one always gets "D. Werner" as the labelname even though no other Werner appears in a citation label.

[plk]

Ah, right of course, how silly. As I feared, we need another skip* option to be more specific. I'll look into it.

[plk]

Hmm, now I actually think about this, it's quite hard. It's not as simple as just generating uniqueness information for related entries - it depends on the user code - you only want to generate it for related entries if any name information is extracted and displayed from the related clones and that's impossible to determine in biber. We could have a biblatex option that says "generate uniqueness information for related entries" but even that's not right as some related entries might be used to display name information, some not and then we'd get the issue you see in some cases. For now I've reverted this on the dev branch as just disabling the skiplab test for uniqueness is clearly not the right thing to do.

[aboruvka]

I was thinking of something along the lines of a relatedoptions field that could override the default dataonly setting. If this would make a mess of things, I have no problem with leaving everything as-is.

[plk]

I think something like that is the only way to approach it. It's not messy really. It's just that it's not really ideal (but nothing is for this situation) because you have to define an option in the .bib which can't really know how you plan to use the entry in the style so they have to be in sync. That's a user problem but it's a bit of a pain as you have no visibility of the option at the style level. However, it's better than nothing.

[aboruvka]

True. Perhaps it's best to leave it at dataonly. I could look into an alternative solution with a cross-reference.

[plk]

Well, actually, the "relatedoptions" idea isn't so bad - it could be used to set the per-entry options on the related entry clone and would replace the default "dataonly". We could then have a "skipunique" option which is part of dataonly by default. Then you could set "relatedoptions = {skiplab, skipbib, skiplos}" and thus avoid skipping uniqueness generation?

[aboruvka]

If you think it's worth adding, then I'm OK with that. I think I will revise the solution to use cross-referencing at TeX.SE in any case. So if you're planning on making any changes, feel free to make them a low priority.

[plk]

I will look at it quickly so it's off my mind. I think we don't need a new "skipunique" option, we just need dataonly to set per-entry "uniquename=false" and uniquelist=false" by default and let relatedoptions override this.

[aboruvka]

OK. (I forgot that uniquename and uniquelist could be set per entry...)

[plk]

1.4/2.4 now updated. If you add "relatedoptions = {skiplab,skiplos,skipib}" to werner2 in your example, it works. Default for dataonly is now "skiplab, skiplos, skipbib, uniquename=false, uniquelist=false". This actually helped me tidy some options code so it was worth it.

[aboruvka]

Very nice. I guess the new field only accepts skiplab,skiplos,skipib? With a name like relatedoptions one might assume that any data valid for the options field could be used: dataonly=true,useeditor=false, etc.

[plk]

It should accept any options which are valid per-entry. It's basically a way to set the "options" field for a related entry that just happens to have a default (dataonly).

[aboruvka]

Sounds good. When I try relatedoptions = {useeditor=false,dataonly=false}, the default seems to persist.

[plk]

dataonly is a strange option and is internally broken down into other options - you can't really set it to false just like any other option - it's only really ever set to true or just not set. Since not setting it is the default anyway, your example should work if you just do:

relatedoptions = {useeditor=false}

This won't set dataonly as that's only set if there is no relatedoptions to override the defaults.

[aboruvka]

OK. I tried again with just useeditor=false, but the resulting bbl file still sets dataonly. If it's working on your end, I'll test with another install later today.

[plk]

Ok, I've actually tested this now instead of theorising about what it will do ...
I've change it so that it won't write dataonly to the .bbl if there is a relatedoptions field. It will write to the .bbl whatever is in relatedoptions. It's a bit tricky because for some options like dataonly, there are parts of what it does which are done by biber, parts by biblatex and so they have to be in sync, optionswise. Everything is updated on SF.

[aboruvka]

Looks good. Thanks!