OASIS Open Document Format for Office Applications (OpenDocument) TC

It was pointed out to me that there is a use case for defining that a table
(that could be in an embedded spreadsheet, or in a text document)
is the data source for a chart.
Imagine a text document with an embedded spreadsheet and another embedded
object which is a chart (the chart is NOT inside the spreadsheet).
Is there already a way to say "this table is the data source for the chart"?
I didn't find a way, so I would like to request one.

My idea would be a new attribute chart:data-source-table-name whose value would be the table:name
of the table (whether it comes from text content or from office:spreadsheet)...
Hmm, this assumes table names are unique, which brings back a recent discussion
to mind about unique ids... iirc we decided that page names would be enforced to be unique,
right? So we could do the same with table names --- except that if they appear to
the user then we need a display-name :-)

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

Dear TC members,

I have just noticed that I missed to forward the following reply from 
Björn Milcke.

Best regards

Michael



Hi David, TC members,

 > /Subject/: *Associating a shape with another shape as its datasource*
 >
 >     * /From/: *David Faure 

Hi David,

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Dear TC members,
> 
[...]
> 
> So the extra attribute we would need in the described scenario would 
> rather be the document into which the ranges point. Currently, we have 
> two situations:
> 
> * a chart has its own data -> means use the chart itself, i.e. "."
> 
> * a chart takes the data from the container document -> data comes from 
> the parent stream in the package, i.e. ".."
> 
> So, technically I would suggest an xlink:href element instead, that 
> points either to "." or to "..". In addition you could use "../Object 
> 2", where Object 2 is an embedded spreadsheet, text document or whatever 
> "data provider", like you describe in your scenario.

My understanding is that the use cases of the xlink:href attribute for 
KOffice would be ".", ".." and other relative IRIs that reference an 
(embedded) document within the same package. Is that assumption correct?

If yes, then I would suggest that we state in the specification that 
only these IRIs are permitted for an ODF 1.2 document. Otherwise we may 
raise the expectation that even http IRIs do work, that maybe is not the 
case for any implementation.

What is your thought on this?

Best regards

Michael
-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

Hi,

based on the conversations we had regarding this topic, I'd like to 
propose that we add the following section to section 10.2 "Charts":

10.2.? Source Document

The xlink:href attribute specifies the document which contains the table 
that contains the chart data. The following values are supported:

- ".": The table is contained in the chart document itself.
- "..": The table is contained in the document into which the chart is 
embedded. This is only supported if the chart is actually embedded into 
another document.
- a relative IRI: The table is contained in the embedded document 
referenced by the IRI. This embedded document must be within the same 
package as the chart itself.

Note: The xlink:href attribute does specify only the document which 
contains the table. The name of the table is specified by the various 
cell address attributes of the chart element's child elements.

If this attribute is omitted, the chart data is taken from the table 
contained in the chart document itself, if that does exist. If the chart 
does not contain a table, then the chart data is taken from the document 
into which the chart is embedded.




Best regards

Michael


Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Hi David,
> 
> Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
>> Dear TC members,
>>
> [...]
>>
>> So the extra attribute we would need in the described scenario would 
>> rather be the document into which the ranges point. Currently, we have 
>> two situations:
>>
>> * a chart has its own data -> means use the chart itself, i.e. "."
>>
>> * a chart takes the data from the container document -> data comes 
>> from the parent stream in the package, i.e. ".."
>>
>> So, technically I would suggest an xlink:href element instead, that 
>> points either to "." or to "..". In addition you could use "../Object 
>> 2", where Object 2 is an embedded spreadsheet, text document or 
>> whatever "data provider", like you describe in your scenario.
> 
> My understanding is that the use cases of the xlink:href attribute for 
> KOffice would be ".", ".." and other relative IRIs that reference an 
> (embedded) document within the same package. Is that assumption correct?
> 
> If yes, then I would suggest that we state in the specification that 
> only these IRIs are permitted for an ODF 1.2 document. Otherwise we may 
> raise the expectation that even http IRIs do work, that maybe is not the 
> case for any implementation.
> 
> What is your thought on this?
> 
> Best regards
> 
> Michael


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

Hi,

as announced in the last TC call, I would like to revise the proposal as
follows. Reason is that the former proposal did not take into account
that a few more sections have to be adapted, and also could lead to the
impression that there is always one table that contains the entire chart
data.


10.1 Introduction to Chart Documents

[This section essentially says the same as the new "Source Document" 
section below. I suggest that we remove it]


10.2.? Source Document

[This section is new]

The xlink:href attribute specifies the document which provides the data
for the chart. The following values are supported:

- ".": The data is provided by the chart document itself. Tt is
taken from the