I have a couple of points about this discussion. 1. I am not sure that XSLT 2 is a wise move at this point, as it will take a while to get good tool support across the various languages and platforms that people will be working with. As a Python developer I see no sign that XSLT 2 is coming - it's hard enough getting good, quick XSLT 1 libraries even now after it has been out for 5 years or so. But it's up to me to do some work, I know.
2. I think it would be worth setting out in some detail the relationship between in-text citations, a bibliography and a data store and CSL showing what these might look like in the OpenDocument format and associated processing applications. I thought I had an idea of how it might work with in-text citations that were essentially tokens referencing a bibliographic data store, but the psuedo code below seems to imply that the full bibliographic record would be in the citation. Or am I misreading it? I have not had time to work on any implementations of CiteProc or CSL at this stage, but I'm still hoping to do so. On 10/13/05, Bruce D'Arcus <[EMAIL PROTECTED]> wrote: > Some background on some of the discussions we've been having recently > (and a hint of why things are sometimes slow!). Below is a note I sent > earlier today to some of the Sun developers working on SW, XML and > OpenDocument. Unfortunately, I learned yesterday that Daniel > (Vogelheim) recently left Sun, which is a big loss. In any case, this > gives a sense of the technical direction that we hope to take. > Daniel's a sharp guy, and we were in complete agreement on all this. > > Peter, I presume the glue code that Daniel mentions towards the end > could also be done in Python ... > > Begin forwarded message: > > > Am still hoping for responses from Sun people to my list posting on > > SW/XML dev. I suppose I'm leaning toward the notion of not worrying > > about adapting CSL to OD, and maybe later thinking about import/export > > support. But whatever the case may be, there needs to be changes > > somewhere in OD to make the functionality we want possible, and we > > need to make some progress on figuring them out. > > > > BTW, am looking through some emails from Daniel earlier. A few > > relevant excerpts: > > > > First, about OD; on notion of embedding bib metadata in wrapper (this > > when we were earlier thinking of using MODS; RDF changes this, but the > > same idea): > > > >>> Thinking farther out, how do we imagine including the bib data > >>> source? I could see embedding a bibliography.xml file in the > >>> wrapper optionally. If yes, does that in any way get controlled? > >>> > >>> We're wanting to use MODS, of course, and there would be value in > >>> standardization. > >> > >> Full agreement on the bibliography.xml stream in the wrapper. And > >> yes, for interoperability this should be standardized as well. Since > >> I don't really know about bibliography data, I'm fine with MODS. I'm > >> sure the TC would go along as well, since MODS is standardized. > > > > To me is this is the most important issue to tackle now, and this is > > OD territory. WRT to the RDF question, I would say RDF is also > > standardized (as a model). > > > > On details of integration (from last August; Oliver mentioned > > something like this more recently): > > > >>> To go back to this subject -- how the actual formatting might happen > >>> -- what's your perspective now? > >> > >> The same, really. As I've mentioned in another mail, the part that > >> reads the bibliography entry and stores it in the document does not > >> yet exist. > >> > >> There's semi-good news on that part, in that I brought the subject up > >> with another Writer developer (who's got more say than I do). He > >> agreed on the approach, and essentially said we'd need such a > >> mechanism anyway for all sorts of extensions. So there's a good > >> chance we'll do that eventually. It will likely be in the > >> help-to-self-help form, in that we'll provide some kind of mechanism > >> for external components to hook into writer and be responsible for > >> certain kinds of embedded data. Such components would still need to > >> be written by non-Sun people. The bad part is that the chances we do > >> this now are close to zero. > >> > >>> I ask because I've decided to start working on my own solution using > >>> XSLT 2.0. The stuff could probably be ported back to 1.0, but it > >>> turns out to be rather complicated problems that need to be solved. > >>> For example, to get this rendering is deceptively complex, and > >>> involved create a virtual tree of the entire bibliography: > >>> > >>> (Doe, 1999a, 1999c) > >> > >> Sounds fine. Since right now full runtime integration isn't likely to > >> happen, I don't see any problem in using XSLT 2.0. I would hope that > >> in the next version (OOo 2.1 or something) XSLT 2.0 would be > >> available. But that of course depends on the adoption of XSLT 2.0 by > >> other parties. We just hook into other people's XSLT processors. > > > > Note: on above, there's a developer in Australia looking at porting > > citeproc to Python + XSLT 1.0, so that may be a possibility. > > > > Later, on possible glue to integrate citeproc-like XSLT processing: > > > >> To provide a straw-man of what I *hope* it would look like: There is > >> some OOo glue (C++, Java, StarBasic) which would basically look > >> something like this: > >> xBibs = new com.sun.star.xml.dom.XDocument > >> xFields = xDoc.getFields.getEnumeration > >> while( xFields.hasMoreElements ) > >> xField = xFields.nextElement > >> if( xField is bibliographic field ) > >> xBibs.appendNode( xField.content ) > >> ' now we have a DOM tree with all bibliographic reference > >> call XSLT-processor on xBibs > >> ' now write back results > >> xFields = xDoc.getFields.getEnumeration > >> while( xFields.hasMoreElements ) > >> xField = xFields.nextElement > >> if( xField is bibliographic field ) > >> xNode = find-proper-node( xBibs ) > >> xField.representation = set representation from xNode > >> > >> How that makes any sense to you... The acutal work would be in the > >> 'call XSLT-Processor' line. The remainder would be the OOo-specific > >> glue. I don't think we'd get by without it completely. Ideally, with > >> some care, the same XSLT could be used for off-line processing, i.e.: > >> unzip -p bla.sxw content.xml | xsltproc bib.xslt > content.xml > > > > This just gives a hint of what I've been saying: I've gone over and > > over this for the past two years, and I'm tired. I want to start > > making some progress, and the most likely place to do that is to > > figure out how to integrate the bib metadata and citation solution in > > the context of the metadata-in-RDF discussion. The stuff that Andreas > > and Oliver do will have to wait, but those are implementation details. > > > > Bruce > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Peter (pt) Sefton Toowoomba 4350 Queensland, Australia Phone: +61 4 1032 6955 Web: http://ptsefton.com Email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
