David,

What you're reporting might be a bug introduced in a recent release.  I'll
take a look.

-Vic



On Wed, Jan 5, 2011 at 7:24 AM, David Bullock <[email protected]> wrote:

> I was surprised today when I saw this in one of my table entries:
>
>         <gs:header row='1' />
>         <gs:data insertionMode='overwrite' numRows='10' startRow='2'>
>             <!-- more columns omitted -->
>             <gs:column index='A' *name=''*/>
>         </gs:data>
>
>
> A couple of days ago, the same entry had been defined with:
>
>         <gs:header row='1' />
>         <gs:data insertionMode='overwrite' numRows='10' startRow='2'>
>             <!-- more columns omitted -->
>             <gs:column index='A' *name='ID'*/>
>         </gs:data>
>
> (note that the name has changed from 'ID' to '')
>
> On a whim, I open up the worksheet, and sure enough, whatever I change cell
> A1 to is what turns up as the column name in the tables feed.
>
> This isn't the behaviour I expected.  Since I:
>
>   a) am forced to supply the <gs:data/> section when I
>   b) am forced to rely on column names when providing the 'sq' query
> parameter on the records feed
>
> therefore, I rely on column names *remaining as I defined them when I
> inserted the table entry into the feed*.  The names I choose to assign to
> the columns are my special, table-specific names for those columns which
> happen to suit my needs for working with the records in those tables.
>
>
> In other news, there's also a <gs:options allCols='false' allRows='false'/>
> in the feed, which isn't specified in the Spreadsheets 3.0 reference guide
> or the RNG schema for the table feed at
> http://code.google.com/apis/spreadsheets/data/3.0/schema/table_atom.rnc
>
> Can you guys like, refrain from making *unannounced* changes to the
> semantics of the feeds?
>
> Now, can we please sit down like server and client and nail down the actual
> contract specified by the table feed? The SS 3.0 guide and reference are
> quite inadequate on the significance of the <gs:header/> versus the need to
> specify <gs:columns/> (one of these must necessarily be ignored by the
> server, yet they are both mandatory in the <entry/>).  Please explain what
> *should* happen, because I can't actually determine it from the docs.
>
> Amazed in the wrong kind of way,
> David.
>

Reply via email to