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] Fw: Proposal: Add multiple cell ranges support to Data Pilot


Inactive hide details for Kohei Yoshida ---07/07/2008 10:46:43 PM---Hello Fei Jia (or how should I address you properly?),Kohei Yoshida ---07/07/2008 10:46:43 PM---Hello Fei Jia (or how should I address you properly?),


From:

Kohei Yoshida <kyoshida@novell.com>

To:

Ming Fei Jia/China/IBM@IBMCN

Cc:

office@lists.oasis-open.org

Date:

07/07/2008 10:46 PM

Subject:

Re: [office] Fw: Proposal: Add multiple cell ranges support to Data Pilot





Hello Fei Jia (or how should I address you properly?),

On Fri, 2008-07-04 at 14:35 +0800, Ming Fei Jia wrote:
> Hello Kohei,
>
> Changing the existing table:cell-range-address attribute to allow a
> list of cell range addresses seems not appropriate because
> "cell-range-address" is just a single range, and can not contain the
> meaning of multiple ranges.

>You're correct; the current spec does not allow multiple cell ranges to
>be given in this attribute.  What I was proposing was to change the
>current schema definition for the attribute from cellRangeAddress to
>cellRangeAddressList so that including a list of cell ranges would be
>legal.

Actually, I mean it is not appropriate to propose that extend "table:cell-range-address" to include multi cell ranges.

> But based on your idea, I can suggest 2 options for this proposal:
>
> Option 1: define <table:table-source-cell-ranges> which contains more
> than one child element <table:table-source-cell-range>. The schema
> looks like:
>        
>          <define name="table-source-cell-ranges">
>                <element name="table:source-cell-ranges">
>         <oneOrMore>
>         <ref name=table-source-cell-range>
>         </oneOrMore>
>                 </element>
>          </define>

>This would allow potentially different filters to be applied to each of
>the source cell ranges, while the original proposal would only allow one
>filter for all the specified cell ranges.  So, I'm personally a little
>hesitant on Option 1.
It seems there is no reason we restrict all the specified cell ranges to only one filter condition. IMO, this option seems more smoothly because it builds upon the existed element <table:source-cell-range>, as well as resolve the relationship between <table:source-cell-ranges> and <table:source-cell-ranges>. Here the problem is that when only one cell range is the table source, according to the above definition, both <table:source-cell-range> and <table:source-cell-ranges> can express the source. So I suggest to change the above tag <oneOrMore> to <twoOrMore>. The means, when only one cell range as table source, we use <table:source-cell-range>, when more than 1(>=) cell ranges as table source, we use <table:source-cell-ranges>.


>
> Option 2: use the existing attribute
> <table-source-cell-range-addresses> (draft 7.v2, 18.963 ) to define
> the element <table:table-source-cell-ranges>. The schema looks like:
>         <define name="table-source-cell-ranges">
>                 <element name="table:source-cell-ranges">
>                         <ref
>         name="table-source-cell-ranges-attlist"/>
>                         <optional>
>                                 <ref name="table-filter"/>
>                         </optional>
>                 </element>
>         </define>
>         <--Sure, table-source-cell-ranges-attlist is not existed in
>         the current spec, this proposal need to define it:-->
>        
>         <define name="table-source-cell-ranges-attlist"
>         combine="interleave">
>         <attribute name="table:source-cell-range-addresses">
>         <ref name="cellRangeAddressList"/>
>         </attribute>
>         </define>

>This is the original proposal with the attribute defined.  I personally
>prefer this to Option 1.  

Right.

>I would still think that we should specify
>what to do when both <table:source-cell-range> and
><table:source-cell-ranges> are given, or when <table:source-cell-range>
>is given but <table:source-cell-ranges> is not.

>Also when saving, should an ODF application create just the
><table:source-cell-ranges> element, or should it create both
><table:source-cell-range> and <table:source-cell-ranges> for backward
>compatibility?  If so, which range should be given in the
><table:source-cell-range> element?

Like the option 1 change, if we add the restriction that <table;source-cell-range> only applies to one cell range scenario, and <table:source-cell-ranges> only applies to more than 1(>=2) cell ranges scenario. Your 2 issues should be resolved.

>IMO, changing the existing attribute definition for
>table:cell-range-address to allow multiple cell ranges (as I proposed in
>my previous post) would eliminate this backward compatibility issue.
>The only drawback with this would be the inconsistency with the
>attribute name (a singular "address" name containing multiple
>addresses).  But there is a precedence for this, especially in the
>definition of the chart data.  Take a look at the following schema
>definitions:

>  * chart-title-attlist
>  * chart-plot-area-attlist
>  * chart-categories
>  * chart-series-attlist
>  * chart-domain

>where a list of cell ranges are allowed in a singularly-named attribute.
>So, at least we won't be the first one to break the inconsistency here.

>Do other people on this list have any opinion on this?

Purely naming issue. IMHO, we adopt this work around solution only we have no better alternative.


Kohei

--
Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc.
<kyoshida@novell.com>




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