Hello to everyone,
I was quite busy recently, therefore please accept my apologies for
responding so lately.
I wish to discuss 2 points:
1. there were some concerns that an advanced approach using a
*high level graphical language* would break the ODF standard
-- *I see NO reason* why this would be so
2. If the script is only used for initial creation, you can never allow
a data update
when the user has already changed something
-- I found a beautiful *solution to this problem*
-- solves a different problem NOT related to implementing the High
level graphical language, too
-- *HOPE it gets implemented* independent of this issue
2. *Data Update*
I will start with the 2nd point. Because real life examples are always
better I will describe some work I have done early in 2006 and the
problems I faced with the current Chart implementation. This comment
will be structured as follows:
a.) real CHART example
b.) PROBLEM
c.) generic solution
a.) Early in 2006 I examined bacterial resistance trends in a county
hospital in 2 time periods (late 2004/ early 2005 AND late 2005/ early
2006: I will refer to those time periods as 2004 and 2006).
The aim of the study was to compare the resistance rates in the 2 study
periods. HOWEVER, it makes NO sense to directly compare the 2 resistance
rates, because:
- there might be distinct (proportions of) bacterial populations in the
2 periods
- different bacteria have usually specific resistance profiles
- so it makes sens to compare the resistance only for a particular
bacterial species (aka it makes NO sense to compare apples with bananas)
- still it makes sense to show a chart with the bacterial resistance in
a specific time period, because empirical antibiotic treatment is based
on this global resistance
b.) The PROBLEM
- I generated 2 bar charts for the resistance rates in the 2 time
periods (2004 and 2006). As explained, it did NOT make sense having one
chart comparing the 2 rates directly (BUT it makes sense showing at
least the 2006 chart for empirical therapy)
- I generated 2 pie charts for the bacteria isolated in the 2 time periods
- I generated 6 bar charts comparing the individual bacterial species
between the 2 periods (there were 6 groups of more common bacteria, S.
aureus, P. aeruginosa, E. coli, Klebsiella spp., Proteus spp. and
Enterobacteriaceae as a group)
- I made extensive annotations/ choose different colours (because
defaults are so ugly) to all these charts: edit long list of
antibiotics, add complex titles, *p values*, extensive legends - these
should be identical (or equivalent) in all charts
The problem is, that *ALL* the chart pairs *should look the same*, in
other words I had to repeat all those expanded changes/customizations
over and over again. I would have welcomed a method to automatically
copy ALL these changes to the new charts.
c.) SOLUTION
So, the previous problem is similar to the problem pointed out
previously for my idea (“you can never allow a data update when the user
has already changed something”) - *aka apply user changes automatically
to a chart*
The basic idea is the following:
- [store the original script (high level graphics language) that
generated the chart - for graphics language]
- store any changes made by the user as a diff to this initial chart
[diff to the xml objects generated by OOo/ the VM in the case of the
graphics language]
- store the final “xml version”, too, to allow for faster
loading/display times
(BUT this is NOT the working version and should be recalculated
whenever some changes occur)
-- this is similar to the *java script* in web pages
-- actually, OOo saves everything using xml-tags,
so this is basically a script acting on the xml, changing the
specific xml tags /
adding new xml tags related to the chart
-- because this is a java-like script, there is no problem in saving
these along the ODF format (like any other java script/macro)
*BENEFIT*
- we can use this script to change other charts, too (e.g. to solve the
problem I described previously with the bacterial resistance)
- hardcoding such functionality directly into the chart code, will make
the code *more and more complex*, especially as more *customization
options* become available!!! (and users including me, will press for
more customizations)
- my approach is more transparent, more easy to implement and more easy
to expand
1. *High level graphical language vs ODF*
Ingrid Halama wrote:
Leonard Mada wrote:
> My intention was to create a *high level graphical language*
> that would be interpreted to some low level *OOo objects and classes*,
> NOT to low-level graphical shapes.
In contrast storing the high level information that you are willing to
create would need
a more complicated additional file format definition.
Please keep in mind that ODF is a standard.
...
... [It is] possible to store those low level objects relative easily
as they have a file format definition already.
I do *NOT* understand, why such a high level graphical language would
NEED an ODF modification. After extensive thinking I could not find any
reason why this should be the case (however please keep in mind, that I
do not have wide knowledge of the ODF format; still there is no sensible
reason).
This high level graphical language should be interpreted by a VM inside
OOo to valid OOo classes and objects. The storage inside the ODF
document would be as usual, nothing different. Although see my comments
later.
There wouldn't be a problem, *EVEN IF* we decided to *save this script*
in the document (which would be the ultimate goal, because users may
tweak or expand these scripts or create new ones – in order to be able
to open the file on every machine, it is necessary to have the script, too).
Currently it is possible to save various macros, e.g. *java script*, so
this is NO different. We would just save another macro, this type
written in a *high level graphical language* which is interpreted
internally by OOo. And just as for a formula, it would get
"recalculated" / "re-RUN" whenever it becomes necessary.
Many thanks,
Leonard Mada
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
