OASIS Open Document Format for Office Applications (OpenDocument) TC

Greetings! http://tools.oasis-open.org/issues/browse/OFFICE-3662 raises the issue of adding these four values to: step-start step-end step-center-x step-center-y to chart:interpolation. In passing it is mentioned that some applications have other values. Two questions: 1) Anyone (Andreas?) care to venture the definitions for these steps. 2) Are these all that we want to add? If there are others and we think there is user demand for them, let's add them now if possible. So we don't have to return to this attribute. Hope everyone is having a great week! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

On Wed, 2011-11-02 at 14:19 -0600, Patrick Durusau wrote: > Greetings! > > http://tools.oasis-open.org/issues/browse/OFFICE-3662 > > raises the issue of adding these four values to: > > step-start > step-end > step-center-x > step-center-y > > to chart:interpolation. > > In passing it is mentioned that some applications have other values. > > Two questions: > > 1) Anyone (Andreas?) care to venture the definitions for these steps. The definitions for the above 4 are already attached to the JIRA issue. See the beginning of the "resolution field" where is refers to http://www.oasis-open.org/apps/org/workgroup/office/email/archives/201106/msg00014.html That message has an ODF file attached with the details. > > 2) Are these all that we want to add? If there are others and we think > there is user demand for them, let's add them now if possible. So we > don't have to return to this attribute. I am planning to provide further definition (Those provided by libgoffice, ie. the ones are available in Gnumeric.) It would be good to have somebody from some other implementations to see what they are really doing. Adding these 4, may also flush out further suggestions in the first public review of these changes. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

On Wed, 2011-11-02 at 14:43 -0600, Andreas J. Guelzow wrote: > On Wed, 2011-11-02 at 14:19 -0600, Patrick Durusau wrote: > > 2) Are these all that we want to add? If there are others and we think > > there is user demand for them, let's add them now if possible. So we > > don't have to return to this attribute. > > I am planning to provide further definition (Those provided by > libgoffice, ie. the ones are available in Gnumeric.) It would be good to > have somebody from some other implementations to see what they are > really doing. > > Adding these 4, may also flush out further suggestions in the first > public review of these changes. Sorry, I confused interpolations with trend lines. At this time I am not planning to suggest to add further interpolations. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

On Wed, 2011-11-02 at 15:36 -0600, Andreas J. Guelzow wrote: > On Wed, 2011-11-02 at 14:43 -0600, Andreas J. Guelzow wrote: > > On Wed, 2011-11-02 at 14:19 -0600, Patrick Durusau wrote: > > > > 2) Are these all that we want to add? If there are others and we think > > > there is user demand for them, let's add them now if possible. So we > > > don't have to return to this attribute. > > > > I am planning to provide further definition (Those provided by > > libgoffice, ie. the ones are available in Gnumeric.) It would be good to > > have somebody from some other implementations to see what they are > > really doing. > > > > Adding these 4, may also flush out further suggestions in the first > > public review of these changes. > > Sorry, I confused interpolations with trend lines. At this time I am not > planning to suggest to add further interpolations. > I wasn't as confused as I thought. A small bug in the current development version of Gnumeric hid some of the interpolation methods implemented there. So I will be proposing a few more methods: * Cubic spline interpolation with parabolic limits. * Cubic spline interpolation with cubic limits. * Cubic spline interpolation with fixed derivatives at both ends. Rather than adding more attribute values to the chart:interpolation attribute, I believe it would be cleaner (and more in the spirit of the already existing chart:spline-* attribute) to use secondary attributes chart:spline-limits, chart:spline-limits-start, chart:spline-limits-end that would modify the cubic-spline interpolation already provided in ODF 1.2. Gnumeric also provides: * Closed Bezier cubic spline interpolation. Since this is not really a proper "interpolation" method, I am not sure this would be appropriately added here unless other implementations provided a similarly closed interpolation. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

Andreas, On 11/03/2011 04:36 PM, Andreas J. Guelzow wrote: <snip> I wasn't as confused as I thought. That's always a comfort. ;-) A small bug in the current development version of Gnumeric hid some of the interpolation methods implemented there. So I will be proposing a few more methods: * Cubic spline interpolation with parabolic limits. * Cubic spline interpolation with cubic limits. * Cubic spline interpolation with fixed derivatives at both ends. Rather than adding more attribute values to the chart:interpolation attribute, I believe it would be cleaner (and more in the spirit of the already existing chart:spline-* attribute) to use secondary attributes chart:spline-limits, chart:spline-limits-start, chart:spline-limits-end that would modify the cubic-spline interpolation already provided in ODF 1.2. To confirm before you enter them in JIRA: chart:spline-limits chart:spline-limits-start chart:spline-limits-end Valuetype = ? What do we have to reference in current 20:26? (I know it is probably obvious but we should not simply say: apply to 20:26 as appropriate.) On prose for these attributes, let's avoid: 20.51 If the chart:spline-resolution attribute has value 1 this is identical to the chart:interpolation attribute value none. That is really awkward and I am not altogether sure it is necessary. Unless we mean to bind the value of chart:spline-resolution to chart:interpolation? That is if chart:spline-resolution > 1 then chart:interpolation *cannot* have the value of none? Gnumeric also provides: * Closed Bezier cubic spline interpolation. Since this is not really a proper "interpolation" method, I am not sure this would be appropriately added here unless other implementations provided a similarly closed interpolation. Other implementers? Anyone? Hope you are having a great day! Patrick Andreas -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

On Mon, 2011-11-07 at 13:36 -0700, Patrick Durusau wrote: > Andreas, > > On 11/03/2011 04:36 PM, Andreas J. Guelzow wrote: > > <snip> > > > I wasn't as confused as I thought. > > That's always a comfort. ;-) > > > A small bug in the current > > development version of Gnumeric hid some of the interpolation methods > > implemented there. > > > > So I will be proposing a few more methods: > > > > * Cubic spline interpolation with parabolic limits. > > * Cubic spline interpolation with cubic limits. > > * Cubic spline interpolation with fixed derivatives at both ends. > > > > Rather than adding more attribute values to the chart:interpolation > > attribute, I believe it would be cleaner (and more in the spirit of the > > already existing chart:spline-* attribute) to use secondary attributes > > chart:spline-limits, chart:spline-limits-start, chart:spline-limits-end > > that would modify the cubic-spline interpolation already provided in ODF > > 1.2. > > To confirm before you enter them in JIRA: > > chart:spline-limits > > chart:spline-limits-start > > chart:spline-limits-end > > Valuetype = ? Until the proposal is finished, I don't think I am sure which value types will be the most appropriate. chart:spline-limits-start/end are probably going to be expressions that shall evaluate to a number. chart-spline-limits will be some kind of enumeration. > > What do we have to reference in current 20:26? (I know it is probably > obvious but we should not simply say: apply to 20:26 as appropriate.) In 20.26 this would not affect the text for the step functions but it will change the limit handling in the cubic splines. > > On prose for these attributes, let's avoid: > > > 20.51 If the chart:spline-resolution attribute has value 1 this > > is identical to the chart:interpolation attribute value none. > > That is really awkward and I am not altogether sure it is necessary. I am not sure why that sentence is preceded by "20.51" (that's the section describing "chart:spline-resolution".) The purpose of that sentence is intended to provide a definition for b-spline (and cubic-spline) in the case of the resolution 1. Of course one could omit that sentence since in the case resolution == 1 the described method yields the same result as using method none. > Unless we mean to bind the value of chart:spline-resolution to > chart:interpolation? That is if chart:spline-resolution > 1 then > chart:interpolation *cannot* have the value of none? > > > Gnumeric also provides: > > * Closed Bezier cubic spline interpolation. > > Since this is not really a proper "interpolation" method, I am not sure > > this would be appropriately added here unless other implementations > > provided a similarly closed interpolation. > > > > Other implementers? Anyone? My comment wasn't quite correct. The description of the cubic-spline method reflects the implementation in LibreOffice/OpenOffice: If the first and last data point are the same then a closed cubic spline is created otherwise an open one. In Gnumeric one would need to specify whether one wants a closed or open cubic spline, there is no automatic guessing of whether a closed or open spline is used. (Note that an "open" spline with the first and last data point the same simply has a corner at that point. This is something that may be expected by a user and provides a continuous behaviour as the last and first data point approach each other.) So I will make a proposal that allows both behaviours to be specified. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

Andreas, OK, I will defer edits on this issue pending your proposal and any action by the TC. Thanks! Hope you are having a great day! Patrick On 11/08/2011 04:16 PM, Andreas J. Guelzow wrote: On Mon, 2011-11-07 at 13:36 -0700, Patrick Durusau wrote: Andreas, On 11/03/2011 04:36 PM, Andreas J. Guelzow wrote: <snip> I wasn't as confused as I thought. That's always a comfort. ;-) A small bug in the current development version of Gnumeric hid some of the interpolation methods implemented there. So I will be proposing a few more methods: * Cubic spline interpolation with parabolic limits. * Cubic spline interpolation with cubic limits. * Cubic spline interpolation with fixed derivatives at both ends. Rather than adding more attribute values to the chart:interpolation attribute, I believe it would be cleaner (and more in the spirit of the already existing chart:spline-* attribute) to use secondary attributes chart:spline-limits, chart:spline-limits-start, chart:spline-limits-end that would modify the cubic-spline interpolation already provided in ODF 1.2. To confirm before you enter them in JIRA: chart:spline-limits chart:spline-limits-start chart:spline-limits-end Valuetype = ? Until the proposal is finished, I don't think I am sure which value types will be the most appropriate. chart:spline-limits-start/end are probably going to be expressions that shall evaluate to a number. chart-spline-limits will be some kind of enumeration. What do we have to reference in current 20:26? (I know it is probably obvious but we should not simply say: apply to 20:26 as appropriate.) In 20.26 this would not affect the text for the step functions but it will change the limit handling in the cubic splines. On prose for these attributes, let's avoid: 20.51 If the chart:spline-resolution attribute has value 1 this is identical to the chart:interpolation attribute value none. That is really awkward and I am not altogether sure it is necessary. I am not sure why that sentence is preceded by "20.51" (that's the section describing "chart:spline-resolution".) The purpose of that sentence is intended to provide a definition for b-spline (and cubic-spline) in the case of the resolution 1. Of course one could omit that sentence since in the case resolution == 1 the described method yields the same result as using method none. Unless we mean to bind the value of chart:spline-resolution to chart:interpolation? That is if chart:spline-resolution> 1 then chart:interpolation *cannot* have the value of none? Gnumeric also provides: * Closed Bezier cubic spline interpolation. Since this is not really a proper "interpolation" method, I am not sure this would be appropriately added here unless other implementations provided a similarly closed interpolation. Other implementers? Anyone? My comment wasn't quite correct. The description of the cubic-spline method reflects the implementation in LibreOffice/OpenOffice: If the first and last data point are the same then a closed cubic spline is created otherwise an open one. In Gnumeric one would need to specify whether one wants a closed or open cubic spline, there is no automatic guessing of whether a closed or open spline is used. (Note that an "open" spline with the first and last data point the same simply has a corner at that point. This is something that may be expected by a user and provides a continuous behaviour as the last and first data point approach each other.) So I will make a proposal that allows both behaviours to be specified. Andreas -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

On Tue, 2011-11-08 at 14:33 -0700, Patrick Durusau wrote: > Andreas, > > OK, I will defer edits on this issue pending your proposal and any > action by the TC. > I assume that "this issue" does not refer to the step function definitions. That proposal is completely separate from any adjustments to cubic-splines. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

Andreas, On 11/08/2011 04:37 PM, Andreas J. Guelzow wrote: On Tue, 2011-11-08 at 14:33 -0700, Patrick Durusau wrote: Andreas, OK, I will defer edits on this issue pending your proposal and any action by the TC. I assume that "this issue" does not refer to the step function definitions. That proposal is completely separate from any adjustments to cubic-splines. Correct. I will go ahead and insert the step function definitions. Hope you are having a great day! Patrick Andreas -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau