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