[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Associating a shape with another shape as its datasource
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]