preliminary <unknown> design

Hi, Esteemed TC:

Here is a summary of the proposal for the <unknown> element:

<unknown> has a content model of ANY and provides a specializable container for well-known, publicly shared foreign vocabularies (such as MathML, SVG, and ChemML) that don't markup discourse text. 

It is an abuse of the DITA architecture to specialize from <unknown> for textual markup or for custom properties (for that, use <data>). For instance, compatibility with NewsML would be introduced by specializing DITA textual elements like <section>, <p>, and <ph> rather than <unknown>.

To interpret the foreign vocabulary, the specializer must override the base processing.

A specialization of <unknown> may contain one DITA <desc>, <image>, or <object> element to provide alternate content. 

If the <unknown> specialization contains a DITA <desc> element, <image>, or <object> element, base processing must format the supplied DITA element and ignore the rest of the <unknown> content. If <unknown> doesn't contain a DITA element, the base processing may emit a placeholder to indicate the absence of processable content.

The specializer may specialize <desc> so that the content of <desc> will be guaranteed to be valid in the contexts in which the <unknown> specialization appears.

An author can also use the <unknown> element without specializing by supplying suitable processing for the embedded foreign content.

The <object> element allows <unknown> after the <param> elements. The base processing for <object> emits the content of <unknown> as a file at the location specified by the data attribute of the <object> element. Thus, the <object> gets its data from the inline content. In this context, any DITA elements within <unknown> are ignored.

In a future version, we should work on cascading fallbacks for unknown or external objects (either sequential as in DocBook or nested as in HTML).

This design has a flaw in that, because <unknown> has a content model of ANY, the rules allowing one <desc>, <image>, or <object> cannot be validated.  That flaw seems possible to tolerate.

Many thanks to Paul Prescod, Eric Sirois, and Michael Priestley for working on this proposal.

Erik Hennum