You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(17) |
Dec
(26) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(4) |
Feb
(18) |
Mar
(60) |
Apr
(50) |
May
(84) |
Jun
(71) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(52) |
Nov
(20) |
Dec
(4) |
2006 |
Jan
(3) |
Feb
(31) |
Mar
(26) |
Apr
|
May
(4) |
Jun
(11) |
Jul
(175) |
Aug
(196) |
Sep
(57) |
Oct
(26) |
Nov
(2) |
Dec
|
2007 |
Jan
(1) |
Feb
(5) |
Mar
(61) |
Apr
(21) |
May
(12) |
Jun
(20) |
Jul
(118) |
Aug
(122) |
Sep
(15) |
Oct
(37) |
Nov
(206) |
Dec
(114) |
2008 |
Jan
(98) |
Feb
(143) |
Mar
(50) |
Apr
(26) |
May
(24) |
Jun
(98) |
Jul
(97) |
Aug
(83) |
Sep
(8) |
Oct
(22) |
Nov
(4) |
Dec
(10) |
2009 |
Jan
(98) |
Feb
(86) |
Mar
(296) |
Apr
(275) |
May
(114) |
Jun
(123) |
Jul
(230) |
Aug
(223) |
Sep
(209) |
Oct
(51) |
Nov
(35) |
Dec
(51) |
2010 |
Jan
(36) |
Feb
(92) |
Mar
(18) |
Apr
(32) |
May
(96) |
Jun
(118) |
Jul
(65) |
Aug
(57) |
Sep
(50) |
Oct
(26) |
Nov
(179) |
Dec
(87) |
2011 |
Jan
(52) |
Feb
(102) |
Mar
(144) |
Apr
(82) |
May
(95) |
Jun
(34) |
Jul
(29) |
Aug
(27) |
Sep
(11) |
Oct
(16) |
Nov
(58) |
Dec
(31) |
2012 |
Jan
(67) |
Feb
(124) |
Mar
(45) |
Apr
(31) |
May
(40) |
Jun
(48) |
Jul
(83) |
Aug
(36) |
Sep
(108) |
Oct
(41) |
Nov
(49) |
Dec
(19) |
2013 |
Jan
(6) |
Feb
(14) |
Mar
(71) |
Apr
(100) |
May
(37) |
Jun
(3) |
Jul
(9) |
Aug
(55) |
Sep
(64) |
Oct
(66) |
Nov
(35) |
Dec
(41) |
2014 |
Jan
(48) |
Feb
(28) |
Mar
(14) |
Apr
(21) |
May
(44) |
Jun
(22) |
Jul
(23) |
Aug
(27) |
Sep
(10) |
Oct
(12) |
Nov
(10) |
Dec
(9) |
2015 |
Jan
(34) |
Feb
(72) |
Mar
(34) |
Apr
(24) |
May
(8) |
Jun
(38) |
Jul
(20) |
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(23) |
Dec
(5) |
2016 |
Jan
(2) |
Feb
|
Mar
(12) |
Apr
|
May
|
Jun
(4) |
Jul
(8) |
Aug
|
Sep
(28) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2017 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(4) |
Oct
(16) |
Nov
(4) |
Dec
(16) |
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Bruce D'A. <bd...@fa...> - 2004-11-28 19:29:49
|
Here's another minor issue: In my current approach, the raw bibliographic collection is regenerated from the database every time the transformation is run. This may not always be a good idea, particularly in a collaborative context. So, in the OOoBib project we would like to be able to optionally save out the bib file and embed it in the file wrapper. That way, if User X sends their document to User Y, the latter can import any missing records into their local DB (notwithstanding any potential complications with IDs). Other (DocBook, TEI, etc.) users might want that functionality too (in most cases, through a separate file, though I suppose in WordML that data could be embedded in the main document somehow?). Anyway, something as simple as the below might work, where if one is working with OOo, the default is perhaps "bibliography.xml" (since that file will always be unique within a file wrapper). Here I have a top-level parameter to specify the file name. <xsl:template match="/"> <html> <head> <title>Testing</title> </head> <body> <div id="content"> <div id="main-content"> <xsl:apply-templates/> </div> <div id="bibliography"> <xsl:copy-of select="$formatted-biblist"/> </div> </div> </body> </html> <xsl:if test="$bibout"> <xsl:result-document href="{$bibout}"> <xsl:copy-of select="$raw-biblist"/> </xsl:result-document> </xsl:if> </xsl:template> I suppose it might also make sense to have a fallback where if for some reason the db isn't available, the stylesheets could use this external file for the data? Bruce |
From: Bruce D'A. <bd...@fa...> - 2004-11-28 13:39:33
|
I'm cc-ing this to various lists; sorry for the cross-posting, but am=20 not sure exactly where it should be focused: I'm co-project lead for the OpenOffice Bibliographic Project (OOoBib). =20= Along with Daniel Vogelheim, I authored the citation coding schema=20 recently approved by the OASIS TC for inclusion in the file format. =20 This will set the low-level groundwork for dramatically improved=20 bibliographic and citation support in OOo. I am also currently working on another piece of this puzzle: a=20 comprehensive XSLT-based formatting solution that I'd like to just=20 drop-in to OOo. This system uses XSLT 2.0, and communicates with a=20 bibliographic database over http, with no other code required. So, the process is: 1) run the processor (Saxon, in this case) against the source=20= document to scan for all of the citation ids 2) assemble a query based on them 3) request the complete raw bibliographic data from the = database 4) format bibs and citations according to detailed = specifications in=20 a (non-XSLT) XML config file This is basically the bibtex model, only better. One of the reasons I'm quite excited about this is that it really opens=20= up some doors with respect to interoperability. So long as a database=20= can a return MODS XML records based on an http query, it can work with=20= the stylesheets. Given the growing importance of a standardized=20 url-based query system in SRU, there's a lot of promise here. I thus want to start a discussion about how to make this happen in OOo.=20= Details include, how might OOo be enhanced -- by Sun -- such that=20 inclusion of such a mechanism would be as simple as possible (maybe via=20= the proposed 'Intelligent Document Tags' functionality?? )? I want it to be brain-dead simple to integrate from a programming=20 perspective because I want these stylesheets to be useable in a=20 wide-range of XML contexts. So far, I have designed them to not rely=20 on any code other than XSLT, and I want to keep it that way. I also=20 want it to be brain-dead simple for users to install (something like=20 Firefox's extension interface for OOo maybe?). If any Sun engineers want to look at the details (which I hope is the=20 case), please contact me about it. I think the problems we need to=20 solve are rather general problems for extending OOo. The other issue, and the more immediate concern of this note, is about=20= how to integrate with OOo styling system. I'm working on revamping my stylesheets a bit to make them more=20 flexible. The basic idea is, we (I'm getting help) are going to create=20= an intermediate representation, which then gets converted to different=20= output formats (xhtml, OOo, WordML, TeX). So, I need to know how best=20= to design that intermediate representation to work with OOo. Anyway, as a start, let's look at what I do with xhtml: <p class=3D"bibref" id=3D"three"><span class=3D"creator">Amin, A. = </span>=20 (<span class=3D"year">1994</span>) <span class=3D"title ">Post-Fordism:=20= Models, Fantasies and Phantoms of Transition</span><span=20 class=3D"container">, In A. Amin Ed., <span class=3D"title italic=20 ">Post-Fordism: A Reader</span><span class=3D"origin"> (<span=20 class=3D"place">Oxford</span>:<span class=3D"publisher">Blackwell=20 Publishers</span>) </span> <span class=3D"part-details"> <span=20 class=3D"pages"> pp. 23=9645</span></span></span>.</p> Most of the above classes are semantic (metadata), but "italic" is a=20 presentational class. There are really two alternatives: 1) dynamically generate the styling for each class each time (somewhat=20= difficult, and adds processing time). 2) use inline styling for that formatting (e.g. <span class=3D"title"=20 style=3D"font-style: italic">A Title</span>). My question is, how best to handle this in the OOo format? I'm less=20 concerned with how things are necessarily now, than in an ideal=20 approach (OOo will have to be upgraded to support what we're doing=20 anyway). Put another way, what would be the best way to code the xhtml=20= to enable it to be seamlessly transformed to a proper OOo=20 representation? Alternately, OOo code could be used as that=20 intermediate format, so long as it is easy to transform to other=20 formats (xhtml, WordML, FO, etc.). Bruce |
From: Christian B. (B. Development) <bib...@15...> - 2004-11-28 09:39:55
|
What about internationalization issues? Would the title be in original language (for example, chinese letters)? Christian Bruce D'Arcus wrote: > > On Nov 27, 2004, at 6:47 PM, Markus Hoenicka wrote: > >> Just a random example from Pubmed from our friends devoted to >> chemistry: >> Studt2004LewisAdductsoftheSide-OnEnd-OnDinitrogen- >> BridgedComplex[{(NPN)Ta}(2)(mu-H)(2)(mu-eta(1):eta(2)- >> N(2))]withAlMe(3),GaMe(3),andB(C(6)F(5))(3): >> Synthesis,Structure,andSpectroscopicProperties >> >> This may look a little contrived but this was actually the first hit >> I've got from a Pubmed query for "nitrogen". There are certainly >> limits to the usability of including the title. > > > Yeah, I thought of that. OTOH, you could always just grab the first > four words of a title. > > Blog comments pointed out other issues, though. I really don't think > there's an ideal way; that all have compromises. Still, I wonder if > a consensus could emerge about best practical approach? > > Bruce > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Bibliophile-development mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibliophile-development -- Bibliograph: Open Source On-line Reference Management http://www.bibliograph.org Christian Boulanger, Developer Email: bib...@15... Fax und Voicemail: +49 1212 521 703 648 |
From: Bruce D'A. <bd...@fa...> - 2004-11-28 00:53:51
|
On Nov 27, 2004, at 6:47 PM, Markus Hoenicka wrote: > Just a random example from Pubmed from our friends devoted to > chemistry: > Studt2004LewisAdductsoftheSide-OnEnd-OnDinitrogen- > BridgedComplex[{(NPN)Ta}(2)(mu-H)(2)(mu-eta(1):eta(2)- > N(2))]withAlMe(3),GaMe(3),andB(C(6)F(5))(3): > Synthesis,Structure,andSpectroscopicProperties > > This may look a little contrived but this was actually the first hit > I've got from a Pubmed query for "nitrogen". There are certainly > limits to the usability of including the title. Yeah, I thought of that. OTOH, you could always just grab the first four words of a title. Blog comments pointed out other issues, though. I really don't think there's an ideal way; that all have compromises. Still, I wonder if a consensus could emerge about best practical approach? Bruce |
From: Markus H. <mar...@mh...> - 2004-11-27 23:48:55
|
Just a random example from Pubmed from our friends devoted to chemistry: Studt2004LewisAdductsoftheSide-OnEnd-OnDinitrogen-BridgedComplex[{(NPN)Ta}(2)(mu-H)(2)(mu-eta(1):eta(2)-N(2))]withAlMe(3),GaMe(3),andB(C(6)F(5))(3):Synthesis,Structure,andSpectroscopicProperties This may look a little contrived but this was actually the first hit I've got from a Pubmed query for "nitrogen". There are certainly limits to the usability of including the title. regards, Markus Bruce D'Arcus writes: > > I just posted something on my blog about citation/record ids, which is > an issue that I think is going to become increasingly important. > > http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2004/11/27/ > citation-ids > > Comments? > > Bruce > -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
From: Bruce D'A. <bd...@fa...> - 2004-11-27 15:43:19
|
I just posted something on my blog about citation/record ids, which is an issue that I think is going to become increasingly important. http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2004/11/27/ citation-ids Comments? Bruce |
From: Bruce D'A. <bd...@fa...> - 2004-11-25 00:49:41
|
On Nov 24, 2004, at 12:57 PM, Bruce D'Arcus wrote: > This would involve simplifying the driver structure I have now, and > probably moving the current class-parameter-conditioned mods:mods > templates into variables. Minor correction: I mean the mods:modsCollection templates; those that begin with stuff like: <xsl:template match="mods:modsCollection[$citation-class='author-year' or $citation-class='note-bib']" mode="enhanced-bib"> So there I'm using a template in another mode/pass, which is conditioned on the citation-class parameter. In this approach, either the variables would have a similar conditional statement (if that's even possible), or there just be a (rather long and hairy) choose statement. Bruce |
From: M. D. P. <m....@md...> - 2004-11-24 18:18:08
|
Bruce D'Arcus wrote: > > > So my thought is that somehow we create the following variables (which > are, of course, temporary trees): > > - citekeys (the ids for the references in the document) > - raw-biblist (raw mods content constructed based on $citekeys) > - intermediate-biblist (intermediate bibliography created from > $raw-biblist) > - rendered-biblist (formatted bibliography created from > $intermediate-biblist, using a simple output driver) > - intermediate-citations (intermediate citations, created from > $raw-biblist; can include first and subsequent, etc.) > - rendered-citations (rendered citations, created from > $intermediate-citations, using a simple output driver) > > It certainly seems cleaner. Am hoping it's also at least as fast; if > not faster (though this stylesheet is seeming slow on my iBook right > now). Features are essential, but performance is nice too! > > This would involve simplifying the driver structure I have now, and > probably moving the current class-parameter-conditioned mods:mods > templates into variables. > > BTW, I'm also hoping this approach makes more sense in the context of > apps like Word and OOo. > > What do you think? Would this actually work? Looks good to me. As soon as things clear out a bit more I will start at the beginning and run through all of this and see if there are any additional comments I have in concern to the architecture. At that point then we can better understand what needs to happen next. My guess is between 3-4 hour, possibly sooner before I respond back with my comments. Cheers! <M:D/> > > Bruce > |
From: Bruce D'A. <bd...@fa...> - 2004-11-24 18:02:50
|
cc-ing in case you're not on the list yet David ... OK, I was just experimenting with the approach that I think may make more sense, which is to use variables apart from the main document rather than passing around everything from tree to tree over multiple passes (as I do in the current version). Here's a simple example: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0" xmlns:mods="http://www.loc.gov/mods/v3" xmlns:db="http://docbook.org/docbook-ng" xmlns:exist="http://exist.sourceforge.net/NS/exist" exclude-result-prefixes="db mods exist"> <xsl:output method="xml" encoding="UTF-8" indent="yes"/> <!-- grab all the citation pointers --> <xsl:variable name="citerefs" select="//db:biblioref/@linkend"/> <!-- construct a list of unique references to pass to a query --> <xsl:variable name="citekeys"> <xsl:text>(</xsl:text> <xsl:for-each-group select="$citerefs" group-by="."> <xsl:if test="position() > 1">,%20</xsl:if> <xsl:text>'</xsl:text> <xsl:value-of select="."/> <xsl:text>'</xsl:text> </xsl:for-each-group> <xsl:text>)</xsl:text> </xsl:variable> <!-- take list of references, and grab them from a database over http; in this case it's an XQuery to eXist, but it should be parameterized for flexibility --> <xsl:variable name="bibrecord" select='doc(concat("http://localhost:8080/exist/servlet/db/biblio?", "_query=declare%20namespace%20mods=%22http://www.loc.gov/mods/v3%22;", "%20for%20$citekey%20in%20", $citekeys, "%20return%20/mods:modsCollection/mods:mods[@ID=$citekey]"))' /> <!-- create raw bib collection; in a real implementation, this might be where enhancement (grouping, sorting, adding content for processing, etc.) would take place --> <xsl:variable name="raw-biblist"> <mods:modsCollection> <xsl:copy-of select="$bibrecord/exist:result/mods:mods" /> </mods:modsCollection> </xsl:variable> <!-- take raw biblist and format it --> <xsl:variable name="formatted-biblist"> <xsl:for-each select="$raw-biblist/mods:modsCollection/mods:mods"> <p id="{@ID}"> <xsl:apply-templates select="mods:titleInfo"/> </p> </xsl:for-each> </xsl:variable> <xsl:template match="/"> <div id="bibliography"> <xsl:copy-of select="$formatted-biblist"/> </div> </xsl:template> <xsl:template match="mods:titleInfo"> <span class="title"> <xsl:apply-templates select="mods:title"/> <xsl:apply-templates select="mods:subTitle"/> </span> </xsl:template> <xsl:template match="mods:title"> <xsl:value-of select="."/> </xsl:template> <xsl:template match="mods:subTitle"> <xsl:text>: </xsl:text> <xsl:value-of select="."/> </xsl:template> </xsl:stylesheet> Result: <?xml version="1.0" encoding="UTF-8"?> <div id="bibliography"> <p id="Thrift1990a"> <span class="title">For a New Regional Geography 1</span> </p> <p id="Tilly2000a"> <span class="title">Review of Moral Economy and Popular Protest</span> </p> <p id="TimesP2001a"> <span class="title">Senators Stamp OK on Anti-Terrorism Laws</span> </p> <p id="Veer1996a"> <span class="title">Riots and Rituals: The Construction of Violence and Public Space in Hindu Nationalism</span> </p> </div> So my thought is that somehow we create the following variables (which are, of course, temporary trees): - citekeys (the ids for the references in the document) - raw-biblist (raw mods content constructed based on $citekeys) - intermediate-biblist (intermediate bibliography created from $raw-biblist) - rendered-biblist (formatted bibliography created from $intermediate-biblist, using a simple output driver) - intermediate-citations (intermediate citations, created from $raw-biblist; can include first and subsequent, etc.) - rendered-citations (rendered citations, created from $intermediate-citations, using a simple output driver) It certainly seems cleaner. Am hoping it's also at least as fast; if not faster (though this stylesheet is seeming slow on my iBook right now). Features are essential, but performance is nice too! This would involve simplifying the driver structure I have now, and probably moving the current class-parameter-conditioned mods:mods templates into variables. BTW, I'm also hoping this approach makes more sense in the context of apps like Word and OOo. What do you think? Would this actually work? Bruce |
From: Bruce D'A. <bd...@fa...> - 2004-11-23 18:04:59
|
just a test. |