update on grouping/sorting

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

update on grouping/sorting

Bruce D'Arcus
With help from Mike Kay on the xsl list, I managed to fix the grouping
and sorting problems with the author/year class. I now need to go back
and tackle the configurability issue.

There are two schools of thought here:

1)  layout of bibliographies and sorting are so closely related that we
can assume configuring one also means configuring the other

2)  that 1 is not as flexible as decoupling them

In terms of practical design issues, I lean towards 1 because it
suggests an easier interface both in xml editors, and in GUIs.  I'm
thus thinking of this:

<reftype name="article" alternate-sortkey="container-title">
   <creator>
    ...

There's actually a variety of options, including:

1)  coding the alternate key on the child:

<reftype name="article">
   <creator alternate-sortkey="container-title">
    ...

2)  explicitly declaring the main sortkey and conditioning validation
on that:

<reftype name="article" primary-sortkey="creator"
alternate-sortkey="container-title">
   <creator>
    ...

3)  using an element based approach:

<reftype name="article">
   <sort>
     <primary type="node">creator</primary>
     <secondary type="node">container-title</secondary>
   </sort>
   <layout>
     <creator>
       ...

.. or even:

<reftype name="article">
   <sort>
     <primary>
       <node>creator</node>
     </primary>
     <secondary>
       <node>container-title</node>
     </secondary>
   </sort>
   <layout>
     <creator>
       ...

Going this approach would mean moving almost all layout details out of
the XSLT and into CSL.  So if you were using the citekey style, you'd
have, assuming the element-based approach:

<reftype name="article">
   <sort>
     <primary type="node">citekey</primary>
   </sort>
   <layout>
     <citekey>
       ...

... with numeric:

<reftype name="article">
   <sort>
     <primary type="node">number</primary>
   </sort>
   <layout>
     <number>
       ...

... and so forth.

Of course, given there's no need for alternative keys on the above two
classes, this seems overkill from that perspective.  In author-year the
story is different, and the sorting stuff gets complicated sometimes.

I've never really gotten any clear feedback on this, but anyone have
any perspectives?

Also, I'd like to reiterate my call for help testing out CSL on some
real-world styles.

Bruce



Reply | Threaded
Open this post in threaded view
|

Re: update on grouping/sorting

Bruce D'Arcus
Thanks Taco.  I hope you don't mind, but I'm cc-ing my reply to the
list.  Taco wrote and maintains the ConTeXt bib module, so have no
doubt a lot of first hand experience with sorting and grouping issues.

On Apr 26, 2005, at 3:27 AM, Taco Hoekwater wrote:

> Bruce D'Arcus wrote:
>> Taco -- do you have any thoughts on this issue?  The concrete issue
>> I'm trying work out here is how to configure the logic that says
>> "sort on creator name; if not present, then if article, use
>> periodical title, if book use "Anonymous", etc."
>
> What I'd really like is a way to change  the global sort order without
> having to edit lots of places in the style

Yes, I'd like to keep the CSL as simple as it can be.

> , but besides that, I'm
> not quite sure what the best solution would be.
>
> It would be weird to sort 'article' fundamentally different from
> say 'manual', so I believe it makes sense to define an abstract
> sort specification like
>
>   <sortorder primary="author" secondary="year" />

The thing is, there are some reference types that do sort differently.  
For example, a legal case uses the case title as the sortkey.  This is
the example that threw me (I have a few legal documents in the book I'm
working on), and made me reconsider the whole damned thing!

> somewhere on top-level. Then (if needed) use an extra block in the
> reftype to map element names to abstraction layer:
>
>   <reftype name="article">
>     <sortinfo>
>       <sort type="author" element="creator">Anonymous.</sort>
>       <sort type="year" element="year"></sort>
>     </sortinfo>
>     <layout>
>     ..
>
> But , there will be 'defaulting' problems with this approach as
> well, I'm afraid.

Let me tell what I started to think last night, and see if this makes
sense:

All along I've tried to keep CSL fairly simple.  Where I can, this
means I either make implicit assumptions, or have a parameter that
makes it explicit.

So, the most important parameter is the citation style class.  The
citation class that I'm working on here is author-year.  Other classes
are number, citekey, and note-nobib and note-bib (both footnote/endnote
styles).

I assume most of the sorting logic based on the citation style class.  
So, the citekey class will sort on the citekey (with an option for
author-year sorting), the number class on the number, etc.

Now, the tricky part is that you often have stuff like this in
author-year, if there is no "author":

        if a periodical article, then substitute the periodical title
        if a monograph, substitute "Anonymous"

Now, what dawned on me yesterday is that this complicated substitution
only needs to be configured in the author-year class, and it only needs
to apply to cs:creator.  If I define something like:

<reftype name="legal case">
    <title/>
    ...

Then that title will be there (it has to be).  I don't need to allow
users infinite configurability here, and indeed it will make their
lives (and mine!) easier.

So now I'm just thinking that I model that in CSL (I'm using RELAX NG,
so I can do this):

BibliographyLayout-author-year = element bibliography { ( Creator |
Title ), OtherFormatting }
Creator = element creator { attribute alternate-sortkey {
"container-title", "anonymous", "title" }

... and then have the formatting of "anonymous" defined somewhere else.

How's that?

How does tend to work in m-bib?

Bruce



Reply | Threaded
Open this post in threaded view
|

Re: update on grouping/sorting

Bruce D'Arcus
On Apr 26, 2005, at 3:27 AM, Taco Hoekwater wrote:

> But , there will be 'defaulting' problems with this approach as
> well, I'm afraid.

I should also add that the system has a robust fallback system where
records get categorized into one of three classes, which map to the
article, book, and chapter fallbacks.  I was just working on a function
last night that represents this logic:

   <xsl:function name="mods:use_csl-reftype" as="xs:string">
     <xsl:param name="bibref" as="element(mods:mods)"/>
     <xsl:sequence select="if (mods:csl-reftype($bibref)) then
(mods:csl-reftype($bibref))
        else (mods:csl-fallback($bibref))"/>
   </xsl:function>

So the fallback definitions are required, and one only adds new ones if
they don't work right.  A report, for example, would typically not need
a new definition.

Bruce



Reply | Threaded
Open this post in threaded view
|

Re: update on grouping/sorting

Bruce D'Arcus
Taco's reply:

> Right. Sounds good. The m-bib's bst files do sorting as follows:
>
>  - the author (+year, title)  : cont-au.bst
>  - the title  (+author, year) : cont-ti.bst
>  - the short key a la abbrev  : cont-ab.bst
>  - nothing at all (cite order): cont-no.bst
>
> where 'author' can be the 'AUTHOR' or the 'EDITOR' or the 'KEY'
> from the bib entry, depending on the type. Much like your proposal,
> actually.
>
> Taco