... | ... | @@ -4,7 +4,7 @@ Not a formal subset or profile of HTML or any other formally specified language, |
|
|
|
|
|
HTML Typescript has nothing to do with Word documents or word processing documents -- except that it is designed in large part so that it should be relatively *easy* and *straightforward* to produce from Word Office Open XML (WordML) or .docx source data. So while there is no formal dependency, there is something of a practical one. Our first use for HTML Typescript is to make data available, which is now locked up in Word - so it has to work for that.
|
|
|
|
|
|
Interestingly, the reason it is relatively easy to produce HTML Typescript, in comparison to other alternative target formats for data extraction/conversion, has nothing to do with HTML and everything with how HTML Typescript *breaks down* and *reconceives* the problem of data conversion as a problem in editorial/production, not something separate. We could have used a bespoke XML format for this purpose - except then everyone would have something new to learn. So we exploit a strategic opportunity: HTML/CSS, already a *lingua franca*, also (incidentally) gives us everything we need to represent a "typescript" in process.
|
|
|
Interestingly, the reason it is relatively easy to produce HTML Typescript, in comparison to other alternative target formats for data extraction/conversion, has nothing to do with HTML and everything with how HTML Typescript *breaks down* and *reconceives* the problem of data conversion as a problem in editorial/production -- what we call "data conversion" is neither properly separable from editorial/production, nor even integral in itself. We could have used a bespoke XML format for this purpose - a kind of "word processing ML" - except then everyone would have something new to learn. So we exploit a strategic opportunity: HTML/CSS, already a *lingua franca*, also (incidentally) gives us pretty much everything we need to represent a "typescript" in process.
|
|
|
|
|
|
Among other things, this means that insofar as information available only from Word documents, is frequently ambiguous and underspecified, an HTML Typescript version must ideally mirror -- *reflect*, not resolve -- that ambiguity and underspecification. It should tell us -- albeit in HTML+CSS, a language we can understand -- exactly what we could know from the Word (if we understood WordML) - and no more. It should not make logical leaps, inferences, or even do very much in the way of translation.
|
|
|
|
... | ... | |