This Cousin covers the three main mailing lists for the GNU Enterprise project, gnue, gnue-dev and gnue-announce. For more information about GNUe, see their home page at http://www.gnuenterprise.org. Details of the mailing lists can be found at http://mail.gnu.org/mailman/listinfo/gnue, http://mail.gnu.org/mailman/listinfo/gnue-dev, http://mail.gnu.org/mailman/listinfo/gnue-announce.
It also covers the #gnuenterprise IRC channel. A great deal of development discussion for this project goes on in IRC. You can find #gnuenterprise on irc.openprojects.net:6667, or you can review the logs at http://www.gnuenterprise.org/irc-logs/.
Jason Felice volunteered to do a "request for
proposal" for GEDI.
He was not interested
in the GEDI API itself, but I want to implement an XML schema plus utilities
for managing database schema's in sort of an object-oriented manner, but such
work would make a pretty good foundation for a sophisticated data api.
Reinhard Müller said that the document Jason had seen was
nearly 2 years old and widely outdated. I feel
absolutely sorry for our incomplete and outdated documentation. It's a
pain to see how they are misleading people that look at the project.
We have talked about a webpage redesign. Maybe we should go through the
docs and remove the outdated ones - I believe that no documentation is
better than documentation that simply tells wrong stuff.
Jason also asked are there any thoughts on
making a database designer module for the designer?
Derek
Neighbors said We definitely want/plan/need to
make a database designer module for designer. We have an XML based markup
for SQL table maintenance that supports 4 or 5 different DB's.
Jason asked Do we consider the database a business
object, or do we have neat hat tricks to map between the two?
Reinhard said In our n-tier setup, there
will be the "GNU Enterprise Application Server" which maps business objects
into database tables. The person creating a module for GNUe will design
business objects instead of database tables.
Some days later
on IRC, Andrew Mitchell (ajmitch) asked is
there going to be a different cvs dir for the new geas, or gonna drop it in the
existing dir?
Reinhard Müller (reinhard) suggested
i'll create a new directory "appserver" -
to be consistent with "forms" "reports" etc
. He wished he had
more GNUe time - it hurts so much to see people
wanting to help and not even having time to put them to work
.
Derek Neighbors (derek) asked why
two filter directories? in reports/
. Jason replied
one for your xsl files - and one for
adapters
. He explained if you
look in adapters/filters you'll see raw and sablotron -
/me likes pluggable stuff - even if we never use anything but
sablotron
. Derek agreed.
It was asked if subforms (master/detail) were working in Forms
under Windows. Reinhard Müller (reinhard) said
AFAIK master/detail is working
on all platforms
. Later, Bajusz Tamás (btami)
suggested try master/detail form
wizard in designer
. This wasn't in the 0.1.1
release, but you can find it in
cvs :)
. Designer could be installed from CVS on Windows, as
long as you had all the dependancies, including python -
dont use 2.2 - it has some bugs -
use 2.1
.
It was asked where the two HTML drivers (as mentioned in
there was a java implementation of forms
but that development has stopped long ago due to lack of time
.
Andrew Mitchell (ajmitch) noted there was
work done on a UIwebware driver, dunno what happened to it
.
Derek Neighbors (derek) said i believe
the php implementation is in cvs - or is in process of getting there -
~/cvs/gnue/phpforms
.
There was some discussion about how to do preselect in Forms using
postgresql. Dmitry Sorokin (ra3vat) asked
are you able to fill the form some other
way like manually "start query",
"execute query"?
It was confirmed this worked, so it
was just a problem with the pre-select rather than a more general
database connection issue. Later, Derek Neighbors (derek) confimed
prequery is used by doing
prequery="" - unfortunately it is currently broken :) -
i believe a bug is submitted against it
.
Bajusz Tamás (btami) reported he had sent some
bugs/fix to dcl on i18n issue
. He said supporting 2-byte unicode
in the Microsoft Windows version of GNUe would not not easy, as
win9x doesn't support unicode
-
but with last bugfix i'v sended, my texts in
forms are all correct now - labels, gnue.conf msgs, input, all ok
for 1-byte i18n. He had based this on Dmitry Sorokin's
old fix in 0.1.1 forms
. Dmitry said that
i think we will not switch to unicode in one day
- i'm not ready to do my forms in utf8 right now
. Bajusz confirmed
that, for his fix, encoding=xxx is needed in
form header - and correct defautltencoding in site.py or in sitecustomize.py
too
. There was lots of good information about i18n in the
internationalizing topic in wxpython help
.
Some days later, Bajusz asked jcater: have
you seen my jpg-s about "collapsed" forms?
. Jason Cater (jcater) said
he had received them - but haven't had a chance to look
yet
. James Thompson (jamest) said this is the
fixed font vs non fixed font issue - we can't just move to non fixed font and it
totally screws up some forms
. There was an option in the gnue.conf file to
force fixed width fonts for a particular installation, however. Jason said that
the problem was that, on many systems, including Microsoft Windows 98 and
GNU/Linux, the wxDEFAULT font falls back to non-fixed
width fonts
He added what I *really* want to do
is let the sysadmin specify exactly *what* font to use and if none is specified,
use the wxMODERN
. He had had really bad luck
playing with wx's font system
. James agreed - what
we have today is the result of lots of trial and error which has resulted in something
that "sucks less" - less than what I'm not sure though :)
.
Later, Derek Neighbors (dnWork) asked any chance
specifying own fonts would fix darn ugly dropdown boxes?
He said
they are a different 'size' than the other widgets and
the font appears different in them
. James said
no, own fonts won't fix problem IIRC - we had to put a fudge factor into the dropdown
size calculations , again IIRC - i don't recall why but I'm pretty sure it had
something to do with my tester always running some damn themed desktop vs the default
one I aways stick with
.
James Thompson (jamest) asked what
parts of gnue common should get documented first to be of
the most use to the GEAS conversion?
. Reinhard Müller
(reinhard) suggested db access -
that's the most important imho
. Derek Neighbors
(dneighbo) suggested i think rpc
has to be pretty high up there too - db allows geas to look at
harvesting data - but without rpc no one can use it :)
.
But Jason Cater (jcater) noted that for Reports, he had
got the engine working and a command
line version of it running - so ppl can develop reports and
see what it's gonna be like
, before the client/server
parts were fully operational. He was
thinking the same thing could happen
w/GEAS and Forms - that would allow ppl to start using the
abstraction-qualities of geas - even before we get a
solid/stable server/rpc setup
. Derek was not convinced
- unlike reports, geas is not
usefull w/o client/server other than testing imho
.
Jason said my point was to get app
development started asap
.
James said its possible to
figure out common by using it - so the docs aren't stopping
anything from being developed
. However, Reinhard said
that python doesn't do
"encapsulation" - i.e. it isn't defined which routines
are considered "public" and which ones
"private"
, which made just reading the source
code more difficult. James started documenting the GCClientApp
to get started, then I'll do DB as
it's a bitch
. He would leave RPC until last as the code
base itself is very much a work in
progress
in this area.
Later, James reported in
common/doc there is a common-techref.lyx file
, and asked
for feedback. Several people were having problems installing the
software for various documentation formats, which lead on to a
general discussion about the best format for GNUe documentation.
Reinhard commented actually it's not
funny - but at least it's amusing - that there are less
dependencies to run gnuef than to read it's docs :)
.
Further to
something
extreme odd is going on on win32 - the widget is ok being passed
strings with just \n in them - however it must autoconvert to \r\n
which throws the cursor placement off
. Harald Meyer
(Harald1> said that explains why I hadn't
problems, when I tested it in a small wypython app - did you change
anything, or are there still problems?
James said
I've just been playing - i haven't
applied the latest patches you sent yet
. Harald said they
weren't a complete fix - just an example
of what I think has to be done to convert to \n when storing in the
db. but I'm not sure that making a conversion in _tosqlString is enough
- but as the widget does autoconvert \n -> \r\n, it could
work
.
Derek Neighbors (dneighbo) asked Jason Cater (jcater)
any reason you started a lyx doc
on
GNUe Reports, as opposed to using existing
docbook doc in cvs?
. Jason said I'm 99.8%
sure they cover different parts of reports
. Derek was not -
if the name is reporting concepts i think it
belongs in report proposal [...] if its a users guide then i agree it
should be separate
. Jason said the original document
addresses nothing that I'm addressing
.
Derek said it was a big picture overview
but was meant to be filled with more detail [...] what you are doing now
(the details) were to go in it - im more concerned that we are now going
to have two documents that have a reports overview that will probably
'conflict'
. Jason was clear that they were
COMPLETELY DIFFERENT TOPICS
.
Earlier, Peter Sullivan (psu) asked do we
need to re-think our docs policy
, as the official standard was
docbook, but in practice most people used lyx as they
understandably want to use a wysiwyg
editor
. James Thompson (jamest) said he
just wants docs that 1) don't require me to
program them 2) have tools that actually don't suck
. He had had
extreme difficulty getting docbook to work reliably (on GNU/Linux),
or at all (on anything else). Nick Rusnov suggested
standardizing on the XML docbook would be a
positive move
, as any XML transformation tool could be used to
produce the documents. Texinfo was also suggested. James said
texinfo and docbook have me spending time
programming the docs - instead of programming GNUe
. Nick
suggested use a standardized text format, and
I'll write a perl script to convert them to docbook :)
but
you don't really exploit the logical markup
that way
. James agreed - we really
need chapters, sections, etc - IMHO - if there was any editor that let
me easily write docbook - then I'm ok with docbook
. Nick
commented I coulda sworn abiword supported
docbook
. James said he wasn't a lyx zealot -
lyx sucks too - it just sucks less than
doing it by hand
. Derek thought that
99% of our docbook issues are that of
staleness
as they were still using the SGML version of docbook
- so when you get the docbook tools that
are now xml and xsl there are 'issues'
.
James said he had started to document GNUe Common,
and jcater is (trying) to start on
reports
, but neither of them were keen on doing documentation.
Derek and Reinhard Müller (reinhard) both said they appreciated
the effort put in on documentation. Derek said the
problem with the .txt docs is they are
too incohesive and scattered and often conflicting so when someone
tries to consolodate them and format them its nearly impossible w/o
getting the original authors involved
. He noted
on at least 5 occassions i tried to
consolidate geas docs to no avail
. Jason felt
one large doc is much worse than 5 targeted
docs imho
. Derek felt that was true for developers, but not
for end-users becaues FINDING the docs
is the problem - the idea originally was to have as many small docs
as you want and then create books from them so users had a choice to
search for a targeted doc or get a broader picture on a topic and
garner all the docs for it
. Nick suggested
should take the whole bodice of documentation
and treat it as one book in separate files - 'the gnue book'
.
Derek said that had been the intention.
Later, Derek suggested we could
always use debian-doc which is like a skinny version of docbook
:)
. Nick noted that debian-doc
is being abandoned in favor of docbook
. He felt
docbook xml is probably the best choice
in this day and age, just need some tools and
infrastructure
- there were no
really good frontends though
. Derek said
KDE and FreeBSD just moved to docbook
for all docs - gnome alredy did - and sounds like debian will be -
makes me wonder why [...] there are no good visual editors for
it
.
Daniel Baumann (chillywilly) said he was
working on python ODMG binding
as you can implement the collection
classes in python
. This was documented in
odmg.txt.
He noted that some of them should contain
lists as a member - some contain a dictionary - andn we should implement
the methods for emulating those types
. Methods would also be
needed for operations such as add and compare. He said
I am hoping to get the the point of
difining the odmg collections classes in python
but
I don;t think they'll get done
immediately
.
The next day, Daniel felt that the OMG
wants to do the same as what we are trying to do with gnurpc -
er, well at least have ti be an extensible framework
, citing
some quotes. He noted instead of CORBA
they are going UML to code now - it's wacky shit - they are adding
stuff to UML to help make code generation easier - this is cool as
I always thought the one stop CORBA solution was short
sighted
.
Another day on, Daniel hyperlinked to
an OMDG document outlining
a way to be middleware agnostic - and
use thier existing framework(s) - I think they have seen the error
of their ways of making CORBA the one stop middleware solution in
their standards and went to using UML so as to support multiple
middlewares - I wonder how far along they are in converting all
those IDLs of their 'services' and other standards into this UML
modeling thing
? He also liked
another
article as well.
Andrew Mitchell (ajmitch) noted that
bkuhn on dotgnu list
had suggested another irc meeting for
GNUe, phpgw, and dotgnu over rpc stuff (including jabber )
,
following on from
what's
jabber got to do with it? jabber is sort of a SOAP replacement?
.
Nick Rusnov (nickr) said jabber isn't exactly
a soap replacement
. Daniel said they
call it messagin middleware - that could be SOAP, CORBA, etc. - we can
support jabber as we do all the others - but it's not going to be a
defacto standard or anything - our objective is to provide choice,
imho
. However, please note I am
saying this without even reading the message yet ;)
.
Todd Boyle asked about
Compiere -
Can anybody advise +/- on this thing? Does it
work?
. Derek Neighbors, remembering
It has been a while. If I reember
correctly the biggest knocks were: a. It is java based. b. It only
work with Oracle backend.
Christopher Brown
said the BIG, BIG, BIG problem with Compiere
was that It requires a whopping big pile of software
that is: a) Not open source, and b) VERY nontrivial to install
-
Compiere may itself be "free software,"
but it's only free if you have already sent your briefcases full of money to
Sun and Oracle.
He also didn't like the use of the Mozilla Public
License, as Contributing to MPLed Compiere basically
amounts to giving your code to the vendor.
Todd also asked about possible collaberation between projects.
Derek replied Merging code generally doesnt
work, ego's often prevent it. Collaboration on other levels are good,
but in case of RPC and such interoperation is generally much easier than
10 years ago. GNUe is of course willing to collaborate in any way that is
good for the user.
Jason Cater (jcater) said in the next week, we'll
be doing the first release of Reports - plus a maintenance release of common,
forms, and designer. Some of the commits you see are documentation for Common
so GEAS can get underway again
. Neil Tiffin (neilt) was pleased that
GNUe Application Server (GEAS) was being rewritten in python now, but
its just sad that it will take a while to get back
to working state
Neil asked how to debug python. Jason
said our GNUe-Common includes a
built-in stepping debugger now - just run the app with
--interactive-debugger
. This had just been
added in this past week :) -
but james was showing me all it can do - and it
rocks
.
Derek Neighbors (derek) said he had been helping someone by e-mail
with installing gnue, all the time wondering why no-one else was
chipping in, only to discover it was all going to his local LUG mailing
list rather than gnue@gnu.org. They had now got it working, and he
quoted some feedback received - Can't recall
who recommended gnue for my simple invoice system, but thanks :-)
Took a couple days break from the install problems, and within a
hour or two today, I have most of it working. This is neat stuff.
There were some problems using the master-detail wizard with MySQL,
as the primary key for the master was an auto-increment field that
didn't get created until commit time. Derek asked
this is because he needs to use the
spiff function? that doesnt exist for mysql? the get next id
thing?
. He suggested we might
want to change the 'master/detail' wizard to allow this to be auto
created (the function) as an option
. Jason Cater (jcater)
said that, in principle, auto-sequences
are not a good thing in gnue-land
but this was
not a bad idea
.
Derek Neighbors (dneighbo) asked about progress on the pysablot packages
, as referred to in
I have them mirrored
,
as Nick Rusnov did not have an account on the gnuenterprise server. Jason
had looked into PySablot and the author is active -
he just started a new Python-related project on sourceforge this
month
. Derek said he would rather that the original maintainer would
respond, but im pro adopting it if need
be
.
Later, Nick confirmed he was willing to
maintain pysablot
as an official Debian package
if there is ubstream and docs and a copyright and a
license
. Derek said he believed license
is GPL and copyright is the fellow who wrote it
. He had e-mailed
the developer asking if he was going to
continue its development - and if not would he turn it over to
GNUe
. He said i can probably whip
together a license and copyright file for him and upload to him a new
tar ball for release including at least a README ;) and maybe even a
simple doc :)
. Nick said this would mean he
could upload it to the archive
as
an official Debian package.
Michael Dean (mdeanlt) asked how is reports
going?
. Derek Neighbors (dneighbo) replied
good - we are generating html now -
and text (though poorly formatted)
. Output was currently
to a static file, but its all using pysablot
so we can do inline eventually
. Already
reports support output of file, email, printer,
fax
.
The next day,
Talli Somekh (talli) asked i noticed that there's been
quite a bit of activity with GNUe Reports in CVS the past few weeks - has it's
status of proof of concept changed at all?
. Derek Neighbors (dneighbo)
said the proof of concept works - if you take the
foobulations report and run it, it reads teh database and creates resulting XML
and we have text and html transformations of that XML
. Talli asked if
it was production-ready. Derek said i would say if
you have to be in production like today and you arent willing to 'suffer the
ills' of using growing software then reports is not for you today - IF however
you have a little time before you need to be in produciton i.e. you are coding
production and you have developers on staff that can quickly patch code if for
some reason the reports development team is around - then reports might be a
pretty good bet for you
He added for
immediate focus text and html will be the concentrated outputs - but i am
looking at gnumeric and excell outputs as well - ps, pdf etc will come shortly
but with XSLT they have to go to FO first which i need to study up on
.
Talli asked whether creating new reports
was
a developer or end-user task. Derek said currently
there is no visual report designer though we are expecting that our current
visual forms designer will be easily adapted to the task
. However,
even at time of writing, if they know markup
they can do it - i.e. if they could write an html report they could write
a gnue report right now
.
On the postscript and PDF output, Nick Rusnov (nickr) suggested
someone will have to make a Python FO engine or
else install java.
. Derek said i am
somewhat of an old skool postscript wizard - and im HIGHLY likely to instead
go straight from XML to raw postscript as we have a python libary for
postscript
. Jason Cater (jcater) thought this
would take ENTIRELY too long to write
Nick asked is FO really that complex?
surely its mappable to TeX or something
?
Jason said that the html and text markups are
quick little scripts dneighbo did
, so writing
other output formats will be trivial
. Derek noted that
with nickrs help most of that report for
html has css (so any html person) could alter it without touching any
real 'code' or xslt style sheets
. Eventually,
our designer will allow you to drag and drop
to create reports - i will go out on a limb and say after we nail some basic
reports and iron out some kinks that will be probably high on the list
of next steps
. For client/server access,
fairly quickly we should support clients that
can talk some form of RPC (CORBA or XML-RPC etc) to talk to it
.
Jason confirmed that he had not implemented triggers in
GNUe Reports yet - that'll be 0.0.2
,
but I feel I have enough to justify a first
release
. Talli felt well, a free reports
app is certainly among the holy grails in the free software
world
. Nick said perl has EXCELLENT
report generation stuff - that people rarely use - which is silly,
cause thats what perl is FOR
. Neither Derek nor Jason were
keen on perl as a dependancy.
For the column width tags, Derek was
thinking it will be a lot easier to do
width="" on each tag like you had it before - but we can make the
'designer' do the work - i.e. if in a header row you set a width it
sets teh width for all its children
. Jason said that was possible
- just seems redundant
. Derek clarified
that you could use Reports without Designer - indeed, as of time of writing
you had to - you could certainly use emacs
or vi or anything that would let you edit flat text or xml
.
Talli said we've had many clients begging for
reports, so this will certainly be something that will be on our
radar
.
Derek Neighbors said that DCL (as set up for bug/feature tracking
on the GNU Enterprise project) sent e-mail updates to people who
raised logs directly via their own DCL account, but not (as of time
of writing) for logs raised via the e-mail gateway -
thats somethign i want to
add
. Michael Dean (mdean) said
that could be done, as long as the
From: field matches the email in the personnel table
.
Derek, in the best recursive traditions of GNU, raised a
work order on DCL for this functionality to be added to DCL.
He asked btw: you have an issue
if we maybe shut down the bug stuff on sourceforge for dcl
and route to the gnue version of dcl
? He wanted
to start showcasing the beauty
of dcl :)
. Michael said he would
have to go through it, but would be
better to eat own dog food, I guess
. Derek said that
DCL was already rather usable
when using it for software project
(bugs features)
like GNUe and
with MINIMAL work i think we could
overcome the issues
.
Later, Derek noted yummy dcl
gateway has been patched - if you send email to it for support
with the to: line being the same as what is your user account
there - it will log it as submitted by your user account!
.
The next day,
Jason Cater (jcater) reported woohoo! I submitted my
first DCL patch today
. He had added "Mailer:
noreply-dcl@myhost.mydomain.com" to his email headers - so I can filter the
damn things
in his e-mail client. Since the
From: is always the user's name and the To: is your name - there wasn't much
to filter against - at one point, I was searching for [WO#.* in the subject
but now that the GNU Enterprise project was using DCL as well, he couldn't
distinguish between work orders from different DCL servers. Derek said
i think here i hacked it to always send from a
special account instead of from the 'user' - at some point might want to make that
an option - as right now if i get a ticket and hit reply to all it probably emails
the original ticket submitter - which in a lot of environments might be good
as we really want the end users communicating with
developers through DCL not individual email :)
.
Bajusz Tamás (btami) asked how GNUe Reports would work
without x,y positioning -
i'v used only fixed pos designers before
. Jason Cater (jcater)
said I've used both - and in my experience,
the fixed positions are a quick way to generate reports - but once you
need more than they offer - you are kind of stuck
. Peter Sullivan
said i have been anti-fixed positioning since
before i used a report tool ;-0 - you have exactly the same problem with
simple spreadsheet solutions - fundamentally, y-axis absolute pos breaks
as soon as you get an extra row of data
. Nick Rusnov agreed -
at some point you have to say 'this goes here'
- but up till that point, imho, you should say 'this is that'
.
Jason said there are instances where physical
markup is a necessity - i.e., pre-printed forms - and i plan to allow
for those
. He thought those would
probably be different designer wizards - we haven't actually done the
designer part yet - but I'd imagine you'd pick from a few choices of
"types" of reports
.
Jason Cater said he had mirrored the new version of DCL to the gnuenterprise
website - thought that'd be appropriate seeing as how
he's gnue affiliated and all :)
. Derek Neighbors (dnWork)
noted that the only issue with upgrading DCL was if
you allowed uploaded attachments you will need to move those off some where
and then move them back - mdean suggests making the attachment directory
outside the dcl tree so you dont have to toy with it for upgrades
.
It was asked what GNU Bayonne was.
Daniel Baumann (chillywilly) explained well
for the enterprise it can be used to do voice mail - touch tone phone
systems - like provide a menu
. He wasn't sure about call
forwarding. It basically provides telephony
services like what some sophisticated phone system thingy does but with
a PC and a telephony phone card
.
Later, Jason Cater (jcater) gave
a link
to information about telephony cards, and confirmed
bayonne can communicate directly with office
PBX's - or it can take the place of a PBX - in which you have a complete
call switching center on a linux box - you can use it for voice mail
(multiline) you could use it for interactive touch-tone menus - including
tying back into a database (i.e., pulling up a client's account
information via a phone menu) - ou could program autodialers (that work
with a PBX or just on a plain old telephone line) - it's a pretty impressive
piece of software
. Jeff Bailey (jbailey) said he wasn't aware that
Bayonne did Automatic Call Distribution. Like
call queues, and stuff.
. Jason said I'm
not sure how much out-of-the-box functionality it can do - it's really an
architecture - imho
, based on conversations
with the bayonne guy - I don't know what it will do without a little
coercing by a knowledgable staff
.
Daniel Baumann (chillywilly) asked
anyone use ERDs?
(Entity Relationship Diagrams). He asked
why does ERD remind me of UML
and relationships?
Andrew Mitchell (ajmitch) suggested
because it maps directly to
it?
. He hoped that eventually GNUe Designer would
allow you to basically
design ERDs, select the database to dump the stuff into, then
generate tables, and make forms and reports
.
Daniel wondered why would you
want to use ERD instead of UML?
Andrew said
ERD is a special type of UML
modelling, i think
. Daniel dug up a quote that
implied that Entity-Relationship and the Object Model were
different approaches - ERD for
2-tier people - and UML or something for objects that execute
on the app server
. Andrew thought that this
means that it has to produce
GCDs, and put them in the object repository
. Daniel
wasn't sure.
Later, Daniel wondered if these
2-tier guys even use ERDs - then probably just start making
tables - no one bothers with design these days
.
Andrew asked whether you think there
should be a standalone app that makes ERDs & then splats out
crap via the schema api? or extend designer?
. Daniel
felt ERD isn't really for objects,
imho
unless and until they actually got implemented as SQL.
However, sam thing could be said for
ODMG's model - they do data schema with ODL and functional with OQL
- but you can call methods
. Andrew asked
how we gonna do methods?
. Daniel
suggested very carefully ;)
He
suggested they would make a request - the
methods server would look for the method - and load whatever it found
at run-time - and execute it
. Andrew suggested that
we should use some of the DotGNU stuff
here :)
.
Jason Cater (jcater) asked about
a gnumeric or such spreadsheet xslt script
for our arsenal?
. Derek Neighbors (dneighbo) said he had
started a gnumeric.xsl already -
basically i formatted out in gnumeric what i thought report should
look like and saved it - and dissected the xml to see
. This
produced very verbose output, but most
of them are 'superflous' standard crap - so in essence i dont thing
it will be tremendously difficult
. For Microsoft Excel,
its a little USED fact - but excel while
it doesnt SAVE to xHTML has full support for it
, so
i planned on going xml ->xslt-> ms excel
xhtml
.