OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.
Inactive hide details for Ming Fei Jia---12/15/2008 11:02:38 PM---Kohei Yoshida <kyoshida@novell.com> wrote on 12/12/2008 11:38Ming Fei Jia---12/15/2008 11:02:38 PM---Kohei Yoshida <kyoshida@novell.com> wrote on 12/12/2008 11:38:15 PM:


From:

Ming Fei Jia/China/IBM@IBMCN

To:

office@lists.oasis-open.org

Date:

12/15/2008 11:02 PM

Subject:

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





Kohei Yoshida <kyoshida@novell.com> 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 <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

> > 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.
>
> 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.
> <kyoshida@novell.com>
>
>
> ---------------------------------------------------------------------
> 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 
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]