188 | | source's schema to ours will be needed (or will have to be inferred). |
189 | | (It is likely, for an existing major source, that we would write the schema mapping. |
190 | | For such a source, if we were receiving updates from them regularly, we would want |
191 | | to detect schema changes, or get notification of them. But for a source we draw |
192 | | on regularly, there may be better means of pulling data than CSV files...) |
193 | | |
194 | | |
| 190 | source's schema to ours will be needed. |
| 191 | For an existing major source, it is likely that we would write the schema mapping. |
| 192 | (But for a source we draw on regularly, there may be better means of pulling data |
| 193 | than CSV files...) |
| 194 | |
| 195 | - If the spreadsheet importer developed for GSoC has a schema mapping representation |
| 196 | that it either receives from the user or generates from having the user match up |
| 197 | fields, we should be use the same one. Once past reading in the files and working |
| 198 | with the user, the CSV and spreadsheet back-end processes should be equivalent. |
| 199 | (This isn't intended to imply that we can't change the spreadsheet importer's |
| 200 | representation if needed.) |
| 201 | |
| 202 | - Inferring the schema mapping, or trying to, might be part of working with the user |
| 203 | to establish the mapping. However, people have been working on this since forever |
| 204 | (or at least a couple of decades), and automation isn't reliable. If attempted, it |
| 205 | should be done with the user at hand to verify it, so it would be done as part of |
| 206 | the UI. By the time the back end is called, we should have a schema mapping. |
| 207 | |
| 208 | ==== Possible format and schema mapping representations: ==== |