Re: [office] Associating a shape with another shape as its datasource

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

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 <faure@kde.org>*
 >     * /To/: office@lists.oasis-open.org
 >     * /Date/: Wed, 21 Nov 2007 23:21:32 +0100
 >
 > ------------------------------------------------------------------------
 > 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).
 >

The name of a table or sheet is contained in the ranges that are used at 
different places of the chart, e.g. different objects can take data from 
Sheet1 and Sheet2 of a spreadsheet. So the table names are already 
contained in the specification. The only thing missing is an 
identification of the document in which the tables/sheets are contained.

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.

The advantage of this is, that we have one attribute to describe the 
current situation ("." and ".."), which can be extended by allowing any 
URL into the package, like "../Object 2", and maybe later to other URLs 
like "http://www.something.com/mysheet.ods"; (is that so?)

On the other hand, I am not so sure if this really works out. First of 
all, we would have to make clear that only a certain subset of links is 
allowed. Then, I am not sure how to implement such a relative link into 
another object. The other object might not yet be loaded, so it would 
have to be loaded while the first object (the chart) is still in the 
middle of its loading process (at least in our implementation, that 
requires the data provider during load time).

Also, if a link points to a data source that is currently not 
accessible, we would also need to have proper cached data. In particular 
we would need a range-string pointing into the local-table in parallel 
to every existing range string, and also the range-strings to the 
external data must be remembered in case the document gets loaded. What 
do you do meanwhile? You can not add a new data series when the 
data-source is not available. Would that be feasible, or should it be 
allowed getting mixed data (some local, some from the external document).

I know, these are partly implementation problems, and we are talking 
about a specification. But when we specify a new attribute we should 
also be able to implement it in a correct way.

So, I think in the long run an xlink:href might be the right choice, but 
I am not sure if it is a good point of time to add it right now, 
Wouldn't it suffice to add a complete, prototype-tested set of 
elements/attributes that allow this thing after ODF 1.2? Is this 
scenario really that important that we need the extension right now?

Regards,
-Bjoern Milcke


-- 
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