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]
