Next in thread →
Next in month →
Re: [office] data cache, field name and source field id for data pilottable
Hi Kohei, Some words are truncated in the previous mail, send again. Thanks for your comments. Ming Fei Jia---12/15/2008 11:02:38 PM---Kohei Yoshida <> wrote on 12/12/2008 11:38:15 PM: From: Ming Fei Jia/China/IBM@IBMCN To: Date: 12/15/2008 11:02 PM Subject: Re: [office] data cache, field name and source field id for data pilot table Kohei Yoshida <> wrote on 12/12/2008 11:38:15 PM: > Re: [office] data cache, field name and source field id for data pilot table > > Hi Ming, > > On Tue, 2008-12-02 at 13:18 +0800, Ming Fei Jia wrote: > > > Kohei Yoshida <> wrote on 11/25/2008 06:30:28 AM: > > > > > Re: [office] data cache, field name and source field id for data > > pilot table > > 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 "$BCf9q(B". > > > Of course, this rename shall be unique at least in the current data > > pilot table scope, otherwise, will cause confusing. > > Agreed. We will probably need to working on including some sort of > unique name requirement in the specification. > > > 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. > > How about interoperability with Excel? Excel supports this at least for > the past few versions (and probably more versions before that), and we > frequently receive customer documents making use of this feature. Not > supporting this in ODF means that we'll lose that information once such > document is saved in ODF. To me that is a strong case in favor of > supporting this enhancement in ODF. Make sense. > > Additionally, I can think of a case where the user of data pilot does > not have the ability to change member names because he/she does not have > access to the source data (e.g. external database or cached data). Even > if the user has access to the source data, changing the name of one > member may require modifying a large number of cells if that member > occurs frequently in the associated field. Providing a quick way to > temporarily rename a member name in one location should be a worthwhile > convenience. Yes, a case for functional requirement. thanks for explanation. > > BTW, this proposal of mine: > http://wiki.oasis-open.org/office/display_names_in_data_pilot > > which proposes a super-set of the field display name part of your > proposal (and includes other attributes such as grand-total-name and > data-pilot-subtotal-name), was originally inspired by the > interoperability requirement, and later reinforced by user requests. To > me, that is a strong enough requirement to make this enhancement > worthwhile for inclusion in the ODF standard. I saw your proposal. A few comments here: (1)table:grand-total is enumeration type, and can choose none,row,column or both. So if you want to define display names for grand total, at least define 2 names: one is for row, the other is for column. right? (2)table:data-pilot-sub-total is already defined as an element. Why not just add an attribute table:display-name to the element itself? (3)I do not very understand the table:data-pilot-field-member-marker you proposed. Additionally, I find <table:data-field> in <table:data-pilot-display-info> and <table:data-pilot-sort-info> may also need a display name. Currently <table:data-field> only specifies the source data field name. But here <table:data-field> is an attribute name, and can not contain attribute. So maybe add a new attribute <table:data-field-name> to the element <table:data-pilot-display-info> and <table:data-pilot-sort-info>. Or alternative solutions? Maybe your proposal need to include the 2 places so that we can provide a relative complete solution. > > To me the name table:display-name is more indicative of the purpose of > this attribute, since its value is used for display purposes only. The > name field-name, on the other hand, sounds a little ambiguous for what > the attribute is used for. > > (I'm aware that later you changed this to field-display-name, which IMO > is better in terms of explicit naming. But I still prefer a more > neutral display-name for the reason I outline below.) > > And when other elements need an alternative name for display purposes, > we could re-use this name without conditionalizing its semantics based > on the parent element. As my proposal indicates, the data-pilot-member > element is one such element that could use this attribute. Make sense. A similar case is <draw:display-name>, totally 9 elements re-use the same <draw:display-name>, pls refer to 18.233 in OpenDocument-v1.2-draft7-11.odt. Of course, this re-use has its condition that the display name attribute is just for the element that contains it. Otherwise, we have to specify the explict object name. For example, <table:display-name> is not appropriate for <table:data-field> in the element <table:data-pilot-sort-info>. > Having said this, I'm open to alternative suggestions. > > > > > > > 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. > > I personally don't see any strong case favoring either 0-based or > 1-based. So, your suggestion sounds reasonable to me. I just > personally prefer 0-based numbering for everything unless there is a > specific reason to pick 1-based numbering. But that's just my personal > taste. ;-) > > But like I said, 1-based numbering is fine with me (although it would be > nice to know why Excel chooses 1-based numbering here). MS Excel just uses 1-based IDs. So interoperability makes me incline to 1 instead of 0, :-) As to why Excel uses 1, maybe Doug or Eric can answer. But seems no explicit meaning here, maybe only a taste. > > Best regards, > > Kohei > -- > Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc. > <> > > > --------------------------------------------------------------------- > 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 >
Next in thread →
Next in month →