By the way, it is probably better to look at https://github.com/citation-style-language/documentation/blob/master/specification.txt for the most recent version of the description for disambiguation. I rewrote some stuff after the pull request Frank linked to. In rendered form (pulled straight from the repo):
http://rst.projectfondue.com/api/v1/rst2html/?rst_url=https%3A%2F%2Fraw.github.com%2Fcitation-style-language%2Fdocumentation%2Fmaster%2Fspecification.txt&css_url=http%3A%2F%2Fcitation-style-language.github.com%2Fstyles%2Fcss%2Fscreen.css&output_type=html&callback=&document_output=whole&highlight_style=manni Rintze On Mon, Oct 31, 2011 at 7:36 AM, Frank Bennett <[email protected]>wrote: > On Mon, Oct 31, 2011 at 11:21 AM, andrea rossato > <[email protected]> wrote: > > Frank Bennett <[email protected]> writes: > >> Andrea, > >> > >> Thanks for looking carefully. > >> > >> One issue is very clear. In the > >> disambiguate_ByCiteRetainNamesOnFailureIfYearSuffixNotAvailable test, > >> by-cite disambiguation should cycle through name expansions after > >> adding names to see if anything helps. The processor currently only > >> attempts one "step" of name expansion with this disambiguation rule, > >> which is why disambiguation doesn't occur on the second full name in > >> that pairing. It's a known limitation at the moment, which may be a > >> hangover from days before the disambiguation code was cleaned up and > >> made easier to comprehend and control. I'll look into improving on > >> that when time permits. I agree that it should be possible -- and if > >> you have a running implementation with better behavior, the spec can > >> certainly be amended to that effect. > > > > If I understand correctly you agree that expanding rendered names with > > initials and, if needed, given-names should be done before adding new > > names. This is the way I'm interpreting the spec and this is also the > > way citeproc-hs is coded to do. > > > > Another way to intend disambiguation is first to try to add names one by > > one, then to try with names plus initials one by one, and then to try > > with names plus given-names one by one. This is the way citeproc-js > > seems to work. But this is not the way I interpret the spec. So the spec > > should be amended only if we think this second disambiguation algorithm > > is to be preferred. > > I can see how it would result in an earlier termination in some cases. > I'm not sure when I'd find the time for the revisions to the > processor. What do you think, do you prefer that method (i.e. running > the full add/expand cycle on each name as it is added)? > > > > >> One the last point raised (concerning > >> disambiguate_ByCiteDisambiguateCondition), applying the disambiguation > >> condition after year-suffix is applied would have the same effect as > >> disabling it altogether, since year-suffix always succeeds. I think > >> the current behavior there is probably correct, although there must be > >> very few styles that apply those rules. > > > > Actually year-suffix always succeeds because you add a suffix even when > > there is no year. See: > > > > date_YearSuffixWithNoDate > > date_YearSuffixImplicitWithNoDate > > > > which produce: > > > > (John Doe n.d.-a [Accessed: June 01, 1965]; John Doe n.d.-b > [Accessed: June 01, 2065]) > > > > I must confess that I do not like this solution very much. Actually I > > think that the last disambiguation step (evaluating the style with the > > disambiguate condition set to true) was intended exactly to deal with > > cases where there is not a year to add a suffix to. > > > > On the other hand I understand there may be use cases I'm not aware of > > (which means nothing, BTW) that dictate for such a behavior. If this is > > true the spec should be amended so that the fifth step becomes the > > fourth and the year-suffix is also to be applied to the "no date" term > > when it is used. Still, what happens when it is not used? > > > > Andrea > > > > > ------------------------------------------------------------------------------ > > Get your Android app more play: Bring it to the BlackBerry PlayBook > > in minutes. BlackBerry App World™ now supports Android™ Apps > > for the BlackBerry® PlayBook™. Discover just how easy and simple > > it is! http://p.sf.net/sfu/android-dev2dev > > _______________________________________________ > > xbiblio-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > > > > > ------------------------------------------------------------------------------ > Get your Android app more play: Bring it to the BlackBerry PlayBook > in minutes. BlackBerry App World™ now supports Android™ Apps > for the BlackBerry® PlayBook™. Discover just how easy and simple > it is! http://p.sf.net/sfu/android-dev2dev > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel >
------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
