On Wed, Feb 8, 2012 at 10:37 AM, Bruce D'Arcus <[email protected]> wrote:
> On Wed, Feb 8, 2012 at 10:29 AM, Rintze Zelle <[email protected]>
> wrote:
> > On Wed, Feb 8, 2012 at 9:42 AM, Bruce D'Arcus <[email protected]> wrote:
> >>
> >> > - type-based approach meant styles were kind of brittle (every type
> >> > needed to be fully-specified for formatting to work correctly)
> >>
> >> This issue is more apparent to users in the social sciences,
> >> humanities, and law, which typically cite a far wider array of
> >> document types. If you only cite journal articles and books (which
> >> have very regular data as well), then this weakness isn't as apparent.
> >>
> >> But it's a PITA otherwise.
> >
> >
> > I don't want to go off-topic, but I think that with CSL 1.0 we sometimes
> > still need item-type based conditionals. After removing the fallback
> > behavior we had in CSL 0.8.1, where sub-item types like "report" would
> also
> > test true when the test was for "book", we got stuck with many styles
> with
> > conditionals like:
> >
> > <else-if type="bill book graphic legal_case motion_picture report song
> > manuscript speech" match="any">
> >
> > (I took this from http://www.zotero.org/styles/apa)
> >
> > I don't see a very easy solution for this, unless we clearly define in
> CSL
> > what roles the different item types fulfill, and what fields belong to
> each
> > item type. That might make it easier to create conditionals that test on
> the
> > presence of certain fields that still work consistently between the
> > different CSL-supporting apps (Zotero, Mendeley, Papers, etc.).
>
> I have a hunch that one could simplify the above code by testing on
> the lack of presence of a certain variable.
>
> My point here is not to argue about whether types are ever needed;
> it's to point out a limitation of requiring types for formatting to
> work at all (which is the case in Endnote; it has a "generic" type
> template, but then everything else is separate, no code reuse, etc.).
>
> > There might
> > be other ways to improve the situation, but I perceive this issue as one
> of
> > the main weaknesses of CSL 1.0.
>
> Exactly what is the weakness though? That we removed fallback behavior
> and thus require this? If that's the case, then it's easy enough to
> recreate fallback logic using variables. The design of fallback
> behavior basically said:
>
> if container-title, then:
> if publisher, then:
> type = chapter
> else
> type = article
> else:
> type = book
>
> Easy enough to represent in CSL 1.0.
Sebastian, do you have any thoughts on this? Speaking for myself, I
currently have no clue which item types have which fields available. The
only way to find out would be to check every CSL-compatible app for their
implementation, which would be a lot of work, and there are known cases
whether different apps having different mappings/fields. Things would be
much clearer if the CSL project would define the rules here.
Rintze
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
xbiblio-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
