Re: [dev-biblio] Re: [users-biblio] Work documents on the wiki.

2006-03-30 Thread David Wilson
On Friday 31 March 2006 9:41 am, Matt Price wrote:
> Hi David,
>

> Alternatively, would it make most sense to design the bibliographic
> database next --
Yes that is a task that could be started now. 

I notice I have not included the database design / build task on the 
Developers page. 
http://wiki.services.openoffice.org/wiki/Bibliographic_Project's_Developer_Page

I will add it in.  

> since there are so few C coders here, but many people 
> with some database experience?
>

 Hopefully the DB expert Bruce mentioned will help us through the design 
process.  

> I'm just thinking that if we (I know the first person is a bit iffy
> here, as I'm hardly active) can start parcelling the project up a bit
> better, we might find that there are a fair number of bits that non-C
> programmers can work on.
I am open to suggestions on how to do this. I have had list of tasks up on the 
web site for some years - with not many takers. But we also need to develop 
and document the tasks much better than we have so that people can assess 
what they would be getting themselves into. 

CPH is doing some good work documenting the biblio coding.

>
> Matt
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
---
David N. Wilson
Co-Project Lead for the Bibliographic 
OpenOffice Project
http://bibliographic.openoffice.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev-biblio] Re: [users-biblio] Work documents on the wiki.

2006-03-30 Thread Bruce D'Arcus
On 3/30/06, Matt Price <[EMAIL PROTECTED]> wrote:

> > My interest in porting citeproc to other languages is to prototype
> > this, and gain the experience we need to figure out how best to do
> > this.
> >
> can you expand on this?  e.g. would it be helpful if I tried to work
> up a python port (this will happen relativley slowly till at least the
> end of May though)?

Yes. There's a citeproc-py placeholder at the xbib svn repo:



My coding skills are limited, though, so I've been slowly (!) working
on the Ruby port because it's a more intuitve language for me. But a
Python version would be better for OOo anyway, with the Python UNO
binding.

Probably the best place to start is to finish the unit tests and make
sure the Ruby and Python versions have equivalent APIs.

Bruce

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev-biblio] Re: [users-biblio] Work documents on the wiki.

2006-03-30 Thread Matt Price
On Thu, Mar 30, 2006 at 06:00:34PM -0500, Bruce D'Arcus wrote:
> 
> On Mar 30, 2006, at 5:41 PM, Matt Price wrote:
> 
> >Also very nice to have the "Functional Requirements" page up.  I wonder
> >though whether it might not be a good idea to start prioritizing all
> >these tasks.
> 
> I agree. I think we need to first clean up the formatting, and then 
> work at streamlining everything.

I'll try to contribute

> 
> >Would (5) and (6), which Bruce calls "a separate chunk of code that
> >would  use the UNO interface", be a logical next step after CPH does
> >104?  What form do folks think it should take?
> 
> My interest in porting citeproc to other languages is to prototype 
> this, and gain the experience we need to figure out how best to do 
> this.
> 
can you expand on this?  e.g. would it be helpful if I tried to work
up a python port (this will happen relativley slowly till at least the
end of May though)?

> >Alternatively, would it make most sense to design the bibliographic
> >database next -- since there are so few C coders here, but many people
> >with some database experience?
> 
> Yes, I think so. David and I have talked about this a bit off-list, and 
> I have an early version of an SQL schema up here:
> 
> 
> 
> Feel free to post comments about it here, or otherwise help.
> 

I'll certainly look. 

> Yes. Well, CPH did ask for help with the user list, which is pretty 
> much non-technical. So that's a perfect opportunity for non-coders to 
> help.
> 
> But beyond that, I think focusing on the data model and formatting code 
> (including helping me make sure CSL is everything it should be*) is a 
> good place to being for those of us without C++ skills (which is almost 
> everyone on this list!).
> 
> Bruce
> 
> * I still may create a proposal to bake the logic of CSL directly into 
> ODF, so all the more important.

it's definitely nice to see it looking as though we might actually get
some citation functionality in the forseeable futre!  I look forward
to being able to reocmmend OOo wholeheartedly to my colleagues.  I
just wish we could have this done in time for the next MSOffice --
seems likethe perfect opportunity to get folks to switch.

Matt


> 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

--
 .''`.   Matt Price 
: :'  :  Debian User
`. `'`   & hemi-geek
  `- 
-- 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev-biblio] Re: [users-biblio] Work documents on the wiki.

2006-03-30 Thread Bruce D'Arcus


On Mar 30, 2006, at 5:41 PM, Matt Price wrote:


Also very nice to have the "Functional Requirements" page up.  I wonder
though whether it might not be a good idea to start prioritizing all
these tasks.


I agree. I think we need to first clean up the formatting, and then 
work at streamlining everything.



Would (5) and (6), which Bruce calls "a separate chunk of code that
would  use the UNO interface", be a logical next step after CPH does
104?  What form do folks think it should take?


My interest in porting citeproc to other languages is to prototype 
this, and gain the experience we need to figure out how best to do 
this.



Alternatively, would it make most sense to design the bibliographic
database next -- since there are so few C coders here, but many people
with some database experience?


Yes, I think so. David and I have talked about this a bit off-list, and 
I have an early version of an SQL schema up here:




Feel free to post comments about it here, or otherwise help.

I met a guy on the db list who is a database expert and member of the 
core PostreSQL development team. He is willing to help us refine this, 
which would be really good (nothing like having an expert help out in 
key stuff like this).


I'm also playing with an AJAX-based Rails app based on the schema ;-)


I'm just thinking that if we (I know the first person is a bit iffy
here, as I'm hardly active) can start parcelling the project up a bit
better, we might find that there are a fair number of bits that non-C
programmers can work on.


Yes. Well, CPH did ask for help with the user list, which is pretty 
much non-technical. So that's a perfect opportunity for non-coders to 
help.


But beyond that, I think focusing on the data model and formatting code 
(including helping me make sure CSL is everything it should be*) is a 
good place to being for those of us without C++ skills (which is almost 
everyone on this list!).


Bruce

* I still may create a proposal to bake the logic of CSL directly into 
ODF, so all the more important.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dev-biblio] Re: [users-biblio] Work documents on the wiki.

2006-03-30 Thread Matt Price
Hi David,

On Thu, 2006-03-30 at 17:03 +1100, David Wilson wrote:
> Moving some of our documents to the wiki have proved to be very successful.  
> (The full list is at http://wiki.services.openoffice.org/wiki/User:Dnw  )
>  
> I have add two more documents on the wiki in the hope that this will enable 
> interested people to add to and improve the bibliographic projects' 
> documentation. In the past people have written some documentation but it does 
> not not seem to get used or improved or updated. This will be easier to do on 
> the wiki.
> 
> I have add 'Enhancements need in Writer to support an improved Bibliographic' 
> module http://wiki.services.openoffice.org/wiki/Writer_enhancements_for_OOBib
> 
> and 
> 
> 'Functional Requirements of the OpenOffice Bibliographic Module' 
> http://wiki.services.openoffice.org/wiki/OOoBib_Functional_Requirements
> 
> 
> regards
> 
> 
> David
> 

It's really great to have this stuff on the wiki.  Just added some
comments & made some minor typographical changes to the 'Writer
Enhancements' page.  

Also very nice to have the "Functional Requirements" page up.  I wonder
though whether it might not be a good idea to start prioritizing all
these tasks.  So for instance, given CPH's list of SW tasks: 



> 
> 1) parse the citation data (done)
> 2) associate that with the relevant part of the paragraph (working on
> it)
> 2) save the data in the correct format to disk 
> 3) display the citation *as is* (as a first pass)
> 4) provide hooks for the manipulation of the citation data to produce
> the 
> required format in the paragraph (i.e. a UNO interface for your
> scripts to 
> generate the format you require)
> 
> 5) format the citation for the footnote/endnote (is this needed?)
> 6) format the citation for bibliographic table(is this needed ?)


Would (5) and (6), which Bruce calls "a separate chunk of code that
would  use the UNO interface", be a logical next step after CPH does
104?  What form do folks think it should take?  

Alternatively, would it make most sense to design the bibliographic
database next -- since there are so few C coders here, but many people
with some database experience?  

I'm just thinking that if we (I know the first person is a bit iffy
here, as I'm hardly active) can start parcelling the project up a bit
better, we might find that there are a fair number of bits that non-C
programmers can work on.

Matt

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev-biblio] Work documents on the wiki.

2006-03-30 Thread Bruce D'Arcus
David:

I made a formatting change to one of the items, using description
lists instead. See what you think:



Bruce

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]