Re: [office] data cache, field name and source field id for data pilottable

[Ming Fei Jia <jiamingf@cn.ibm.com>]

Hi Kohei,

Sorry to be late response, I have accumulated hundreds of mails during these days since I am busy in other dev work. My comments are below.Thanks very much for your suggestions.

Kohei Yoshida <kyoshida@novell.com> wrote on 11/25/2008 06:30:28 AM:

> Re: [office] data cache, field name and source field id for data pilot table
>
> On Sun, 2008-11-23 at 23:52 +0800, Ming Fei Jia wrote:
> > Dear TC members,
> >
> > I have created the proposal on the wiki:
> > http://wiki.oasis-open.org/office/data_cache%
> > 2C_field_name_and_source_field_id_for_data_pilot_tables
> > Thanks.
>
> I have two comments regarding this proposal.
>
> 1) An additional attribute to allow an alternative name to a data pilot
> field is a great idea.  I think we should extend that to field members
> as well, to allow alternative names to individual field members since
> that is also something that the users desire to do.
Besides the more human readable, I propose the field name to be allowed to rename is mainly from the consideration that in field reference operation, allow different data view for the same source field. For example, for the same source field "count", which records the product count of each person in one sales report, we can have 2 fields "absolute count" and "relative count" that bind to the same source field "count". And "absolute count" is the normal value view of the source field, the "relative count" is the reference view of the count relative to some specific person's count.

As I understand, field member name specifies the value of data pilot member,currently using the attribute <table:member-name> to represent. What I can see the benefit of allowing member name to rename is the more human readable. For example, for a field "Country", which has 2 values: "China" and "USA". The "China" and "USA" will be 2 field members. In order to be more human readable for Chinese people, we can allow users to rename the member name to the corresponding Chinese string "Öйú". Of course, this rename shall be unique at least in the current data pilot table scope, otherwise, will cause confusing. But I think only human readable the requirement seems not strong enough, could you have any function requirement for renaming member name? That will be better.

>
> For that reason, how about changing the name of the attribute from
> "table:field-name" to "table:display-name"?  That way the same attribute
> name can be used for the <table:data-pilot-member> element as well.  Or
> any other name that can be used both for <table:data-pilot-field> and
> <table:data-pilot-member> would do.
Yes, the table:display-name is more appropriate for this case. When I originally propose, I just used the table:display-name. But then I saw "table:field-name" is already used in the element <table:data-pilot-field-reference>, which has the same meaning with the one in this case. So I use "table:field-name" as the attribute instead of inventing other new attribute name. Of course, I also prefer the table:display-name if no one disagree.
>
> 2) Regarding the assignment of unique IDs to each field in the data
> source, you propose to use the sheet name plus the column label as the
> unique ID.  Why not simply use 0-based numerical IDs?  When the data
> source is loaded, I can imagine internally the data are structured in a
> single tabular form anyway.  So, I would imagine using the column (or
> field) indices of that internal table would make the implementation a
> little simpler.  Doing that would also allow it to be used when the data
> source is not on a local spreadsheet but in an external data source,
> and/or the data source is cached (as in your proposal).
Sure, I just take an example for the ID, not definately a sheet name plus column label. What I propose is only a unique ID that can represent the location of the source field in the data source. As to how this ID is comprised of, I originally do not care much. But now as you said, I think using an index value of the source table as the source field id is better. I've changed the source field id definition in the wiki(http://wiki.oasis-open.org/office/data_cache%2C_field_name_and_source_field_id_for_data_pilot_tables). I checked MS Excel, which uses an index from 1, so I define this ID as postiveInteger in oder to keep good interoperability with Excel.
>
> Kohei
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>