OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Business Charts


Hi all,

Here's some analysis of the chart proposal David posted earlier. I've 
discussed the proposal with our Chart developers, and summarized things. 
Discussion is based on the schema David posted, as well as saved files 
from KChart 1.2.1 (we had trouble installing a 1.3beta).

We didn't find significant differences in expressive power, but of 
course each format covers a somewhat different set of features in 
addition to a siginificant overlap in core functionality. So either way, 
a merge of formats will be necessary. The KChart format doesn't seem to 
be easily aligned with the remainder of the OASIS format, which is much 
less of a problem with the OOo format, since it is used as a base was 
designed to a similar set of requirements as the OASIS format.

The major issues we came up against when comparing the two formats where 
issues of
1) content/layout separation,
2) differing concepts for similar things,
3) arbitrary limits and application artefacts,
4) redundancies,
5) different concepts for remainder of format.

In more detail:

1) Content/layout separation is kept in the OOo chart format in that the 
chart element contains a relatively compact section describing the chart 
content, plus a table containing the chart data. The remaining 
information is stored in (automatic) styles sections and referenced from 
within the content. The KChart format apparently prefers to keep things 
grouped by theme, so that for example the <LegendSettings> and 
<HeaderFooterSettings> contain both the content being displayed for 
legends and headers/footers, as well as where this is to happen. 
Information on the data series to be displayed is distributed over 
several elements.

2) There seem to be different representation for similar things, e.g. 
multiplicity of elements in handled in different ways. For example, some 
elements (in <ColorSettings>) are prefixed with an index number, in 
other cases (DataValueSetttings1/2) it's part of the name, and in yet 
other cases it's positonal (<AxisSettings>).

3) Some limits or encodings seem rather arbitrary, and I suspect these 
are artifacts of the supporting application. For example, there are 13 
<Axissettings>, or the DataSet attributes of LONG_MAX-1, which I suppose 
is a special value in KChart.

4) The KChart format always contains settings for all chart types, even 
if not used. The OOo format uses styles, which allows for storage of all 
settings, but typical use would be to include only the chart styles 
actually used in the current chart.

5) The KChart format, as is, doesn't fit in too well with the remainder 
of the OASIS format. For example, KChart Headers/Footers appear to be 
encoded as one element per header/footer, left/right/center, with three 
header/footer items (each containing one string, one style). This is 
better than the OOo format (which doesn't have any headers/footers for 
charts, but doesn't easily fit with the remainder of the OASIS. 
Extending the OASIS format comes rather naturally, though, by simply 
allowing page styles for charts, which automatically includes headers, 
footers, with arbitrary sequences of paragraphs.


Having said that, the KChart format clearly contains a number of 
features the OOo chart format doesn't have (and vice versa), so we need 
to merge things. I think we should continue to use OOo as base format, 
as that will make integration with the remainder much easier. Also, I 
think the content/style representation of the OOo format makes it more 
amendable to extensions and maintance. What I propose to do is to go 
through David's proposal, adding anything necessary to encode KCharts in 
the OASIS format.


Sincerely,
Daniel


Appendix: A (potentially non-complete) list of features in KChart, which 
are not found in OOo

I've added some comments based on feedback by OOo developers.

* Bar Charts
** ThreeDBarDepth  - KChart uses percentage, OOo fixed numbers. 
Percentage probably makes more sense.
** DatasetGapIsRelative, ValueBlockGapIsRelative
* Area Charts
** Location (Above/Below)
* Pie Charts
** Explode, DefaultExplodeFactor, ExplodeFactors, ExplodeSegment  - 
alternative: store this with the data points
* PieStart (RingStart) - useful, maybe as a data-series property
* RelativeRingThickness - maybe as data-series property?
* Candlestick Chart (aka HiLo-, stock chart)
** Print(Low|High|Open|Close)Values - supported by OOo on the data series?
* Legend
** Position - exists in OOo, but needs more values
* Source
* Title(Text/Font/Position) - add additional element title to legend?
* Spacing  - useful; maybe as percentage?
* Axis
* LabelsTouchEdges - turn into property of axis?
* AreaMode/AreaMin/AreaMax/TrueAreaSize/TrueAreaRect  - careful with 3D 
charts
* ZeroLineColor  - alternative: allow arbitrary number of 
decoration-line elements
* MaxEmptyInnerSpan - ???
* LabelsFromDataRow/TextsDataRow - supported on OOo only for plot area; 
moving to axis is more correct
* ShortLabelString, LabelTexts, LabelTextsDirty
* Dataset/Dataset2 - alternative: explicitly add all attached axis to 
the dataseries element as attribute
* HeaderFooterSettings - alternative: use page styles
* GlobalLeading
* DataValueSettings1/DataValueSettings2 - for primary/secondary chart? 
OOo offers label settings for each dataseries.
* AreaMap, CustomBoxMap



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]