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

[Kohei Yoshida <kyoshida@novell.com>]

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.

> 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.

> 
> 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.  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?

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?

Kohei

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