I have nothing on Ian's question - the only style editor I ever used was for Biblioscape and that only had prefixes and suffixes and it took forever to write a style.
As for testing for item types - I'm not willing to go without. I think there are many cases where it's somewhere between hard to impossible to do that (e.g. dealing with volume #s or page labels), especially if we want to deal correctly with incomplete date (think e.g. a chapter that doesn't have a publisher). But there's a difference between using some type-based testing and _only_ using type-based testing. I took Bruce to object to the latter and I completely agree with that. That said, we should standardize variables for item types, but that's a topic for a different thread. S. On Wed, Feb 8, 2012 at 8:48 AM, Rintze Zelle <[email protected]> wrote: > 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 > -- ------ Sebastian Karcher Ph.D. Candidate Department of Political Science Northwestern University ------------------------------------------------------------------------------ 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
