| 241 | We want the representation to be easy for a person to construct rather than easy for |
| 242 | the importer to use. The importer can always produce an internal representation that |
| 243 | is convenient for running the data conversion. |
| 244 | |
| 245 | There are two main categories of representation: |
| 246 | |
| 247 | - Formatting, such as which of the file layouts is used, what the separator character |
| 248 | is, how the text is escaped, which cells are structured... This is the "parsing" |
| 249 | aspect of the representation. |
| 250 | |
| 251 | - The actual mapping of the source schema to our schema, that is, once we have their |
| 252 | structured objects read in, how do we create our objects out of theirs? |
| 253 | |
| 254 | === Implementation notes === |
| 255 | |
| 256 | //Under Construction -- falling...asleep...// |
| 257 | |
| 258 | The overall process will be: |
| 259 | |
| 260 | - Extract the data into XML. |
| 261 | - Call S3Resource import_xml(). |
| 262 | |
| 263 | The devil is in the (extraction) details. |
| 264 | |
| 265 | Some notes and cautions: |
| 266 | |
| 267 | - Ideally the (internal) schema mapping will be "runnable" -- that is, it can |
| 268 | drive the extraction of data. Actually producing a state machine or similar is |
| 269 | likely overkill. |
| 270 | |
| 271 | - Error handling and feedback must be done without user intervention -- this may |
| 272 | be used in a "lights out" situation where data is received automatically. |
| 273 | |
| 274 | - Need to provide error info in a machine-readable form. |
| 275 | |