... | ... | @@ -48,11 +48,11 @@ Since there is much to be done to get to that point, this means being vigilant f |
|
|
|
|
|
### What should come through and what shouldn't and how do we know?
|
|
|
|
|
|
While the transformation is lossless as respects "main document content" (that is, data that is stored as the nominal "document text" in the Word file), there is also much other data in a Word source file that should come with it (the most obvious: footnotes and figures), and due to the ("database-like") organization of the source data, it is difficult or impossible to guarantee a perfect transformation. Especially since some of the info in the Word document (page headers come to mind as an example) should arguably not come into the HTML.
|
|
|
While the transformation is lossless as respects "main document content" (that is, data that is stored as the nominal "document text" in the Word file), there is also much other data in a Word source file that should come with it (the most obvious: footnotes and figures), and due to the ("database-like") organization of the .docx source data, it is difficult or impossible to guarantee a transformation will never drop data. Especially since some of the info in the Word document (page headers come to mind as an example) should arguably not come into the HTML in any case.
|
|
|
|
|
|
We need to have robust mechanisms for detecting problems in data extraction _especially lost data_, for ameliorating such problems in the instance (sometimes they may not be fatal errors), and for maintaining and improving the XSLTs so they don't happen.
|
|
|
In addition to some means of representing and aligning specifications for the different XSLTs (such as inline documentation), we need to have robust mechanisms for detecting problems in data extraction _especially lost data_, for ameliorating such problems in the instance (sometimes they may not be fatal errors), and for maintaining and improving the XSLTs so they don't happen.
|
|
|
|
|
|
Operationally, what will be the best way to specify corrections / improvements? (Could use Issues on this here gitlab.)
|
|
|
Operationally, what will be the best way to specify corrections and feature requests? (Could use Issues on this here gitlab.)
|
|
|
|
|
|
### Funky structures and math
|
|
|
|
... | ... | |