By using the ENGINE tag it is possible to make use of engine-specific functionality, but the intended use of SABLE is where the markup text is generated quite independently of the engine used to render it as speech. In fact, one can imagine the synthesis engine running on a local machine while the text is generated by some web-based application elsewhere on the net: the advantage of this is that relatively low bandwidth will be required between the machines and high quality audio can be generated locally.
When writing applications that generate SABLE markup it is easy to write in a TTS-engine-independent way. Using relative and descriptive values for attributes such as the PITCH and RATE tags is much more likely to work across synthesizers than absolute values. Also given that engines may potentially ignore tags when they do not support the functionality, the text can be arranged such that this will still sound reasonable.
Since we primarily see SABLE markup being generated by applications rather than written by hand, using an existing standardized markup paradigm makes this much easier. We also envisage stand-alone applications which can translate existing structured documents into SABLE markup. For example, e-mail messages are structured, and a conversion program could be written that marks headers, quoted sections etc. using SABLE tags that would allow any SABLE-compliant TTS engine to render it reasonably. Converters for existing document formats such as LATEX and MS Word could also be written.
In the case where the document format is already an XML/SGML type language, such as HTML, existing document translation systems can be exploited. HTML may be augmented with cascading style sheets (CSS) (http://www.w3c.org/css/) which would make translation to SABLE very simple.