On Feb 6, 2007, at 11:15 AM, Mathias Bauer wrote:
Bruce, can you help us getting a *short* description of the necessary
APIs? Which "language" does Zotero "talk" with Word?
OK, I found it already. :-)
Sorry, been busy, and was waiting on an answer from the Zotero guys.
I had a look on the Zotero Word Integration Alpha and its VBA code. It
seems that they use SOAP to let Word talk to themselves and then
use the
Word API to insert and update the fields based on what they received.
That makes sense.
One thing that the plug-in does not do currently -- but which would
be nice -- is to allow browsing of the database from within the word-
processor. So using the MS example, imagine if instead they used the
Research Pane to be able to connnect to Zotero? They could then also
move from a citation field in document to a source record in the
bibliographic database.
Also, in this scenario, we presume the formatting of the citations
and bibliography is the responsibiltiy of the plug-in, rather than
the word-processor. Given how complicated this part is, it might be
good to avoid that assumption (?).
The ideal use case scenario we enable is that we allow two users --
one using OOo and Zotero and another using KWord and some other
bibliographic app -- to pass their document back-and-forth and for
the citations to remain "live." E.g. the formatting is continuously
updated across sessions.
This is why I've focused on the metadata work in ODF (so it can store
the data), and have been thinking in terms of a generic API. I have
basically been assuming the bibliographic app sends the requested
citation source metadata -- and maybe optional formatted strings --
to the word-processor. But we can certainly discuss other options.
Using the same SOAP interfaces in OOo doesn't look like a problem
to me.
We have developed a generic SOAP client that can integrate SOAP
services
into OOo Basic in a way that they can be used in the same way as UNO
services. The WSDL of the service is used to create an object
dynamical
at runtime. So integrating SOAP calls into OOo Basic is a piece of
cake.
Cool; thanks for that information. I will pass it on and hope we can
get some discusion about details.
FYI, I started a wiki page at the Zotero dev wiki:
<http://dev.zotero.org/docs/word-processor_integration>
That in turns links to a page on the API:
<http://dev.zotero.org/docs/api>
.. where I the abstract API ZOOM, which is implemented in open source
code that implements three different protocols, one of which is SOAP
(SRW; the RESTful version is SRU).
In OOo we still need the extended citation and bibliography support we
already talked about. ATM we can only insert the simple "Bibliography"
text field that is currently available. But I think that you know
that,
Bruce. ;-)
Yes :-)
I assume that e.g. KOffice can use the same SOAP calls as "the
API", of
course the internal API to KWord will be different to what we find in
OOo and Word and so it doesn't matter if they used a different
technology to "talk" to their application.
So my current understanding is that we should go on with meditating
about the SOAP API of Zotero: is this API suitable for our
applications,
and is it a good API for other sources - however they will
implement it:
if we think about other sources for bibliographic content that are
locally installed I assume that using SOAP is not the preferred way of
integration.
Yes, I agree. I will see if we can get a discussion on this. As I say
above, right now the Zotero API is no doubt very simple.
In OOo I would factor out the data retrieval and make it an
installable
"driver" that is integrated via a service provider API. On top of that
we have a UNO service implementing the same API as the SOAP service.
This will enable our extension to work with all sources in the same
way.
source1 -----> file, RPC "drivers" ----> UNOService(1)
source2 -----> SOAP ----> SOAP Client -> Service(2)
(1),(2) have the same "interface" in Basic and be used there
interchangeable:
bibl API Text API
UNO service / SOAP service ----------> data --------> Writer
Thanks Mathias; more later!
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]