|
|
# HTML Typescript
|
|
|
|
|
|
Not a formal subset or profile of HTML or any other formally specified language, but an *approach* to using HTML and web pages -- an adaptation or "use case" that exploits certain features of HTML in view of a particular set of requirements.
|
|
|
Not a formal subset or profile of HTML or any other formally specified language, but an *approach* to using HTML and web pages -- an adaptation for a "use case", that exploits certain features of HTML in view of a particular set of requirements.
|
|
|
|
|
|
HTML Typescript has nothing to do with Word documents or word processing documents - except that it is designed in large part so that producing recognizable HTML Typescript documents is relatively *easy* and *straightforward* to produce reliably from Word OpenXML. 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.
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
... | ... | |