Refine handles joins separate Excel rows together, confusingly

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open Excel file in Refine (attached)

What is the expected output? What do you see instead?
I have a data file of six rows. There are three valid rows, and three that 
appear to be mistakes during a PDF->XLS conversion. Nonetheless, inside Excel, 
there are six distinct rows and I expect to see six in Refine.

Opening the file in Refine says there are just 3 different rows, with the other 
three apparently joined as subrows to their respective "correct" row.

However, visually and functionally, the set of entries act like 6 different 
entries, as the carriage return creates a sub-row for each entry, and Refine 
allows you to edit that subrow separately from what you think should be the 
entire entry.

Screenshot and sample data is attached. I've circled in red the number of 
entries (3 instead of an expected 6) and how I'm able to edit the second row of 
one of the entries, when really, I expect that to be a whole separate entry.

Original issue reported on code.google.com by dan.cao....@gmail.com on 7 Jan 2011 at 9:26

Attachments:

• refine-carraige-return-source.xls
• google-refine-carriage-returns-issue.gif

[GoogleCodeExporter]

Dan, I noticed that your screenshot shows your viewing by *records* rather than 
by *rows*  Can you try clicking on *rows* to see if it fixes the problem?

Original comment by thadguidry on 7 Jan 2011 at 9:42

[GoogleCodeExporter]

Thanks Thad, you're correct, that fixes the problem...I've noticed the 
rows/records distinction but never used it until now. 

Just as a side question, what is the records-layout used for? And how does it 
determine if two rows make up a single record?

Original comment by dan.cao....@gmail.com on 10 Jan 2011 at 4:54

[GoogleCodeExporter]

Some of that is answered in the [ServerSideArchitecture] wiki page and 
describes the Data Model itself.  In general, the records view is used for data 
that would be more useful to view as a record, like XML and JSON data.  But 
it's completely up to you.  The difference is in the Data Model views 
themselves.  Either the Column Model (rows) or the Column Groups (records).  
The underlying Data Model itself doesn't change however, only the views, for 
consistency across operations, transforms, etc, etc.

Original comment by thadguidry on 10 Jan 2011 at 5:46

[GoogleCodeExporter]

User misunderstanding per previous comments.

Original comment by tfmorris on 14 Jun 2011 at 6:34

• Changed state: Invalid