Generic text element
Expand the content model of base elements which contain #PCDATA so that they can also contain a new text element.
The keyword element is often used to store common text such as product or platform names. This is done because keywords are allowed in nearly all locations that allow text. However, it is not possible to combine common strings into one single keyword for reuse. For example, both "Product A" and "Platform B" are common strings, and are often used together as "Product A for Platform B". To use the combined value, users must enter a new copy of each string in another keyword. Alternatively, they could always reference the two in text as <keyword conref="#topic/product"/> for <keyword conref="#topic/platform"/>. So, it is impossible to reuse the string "Product A for Platform B" without repeating text somewhere.Similar issues happen with other elements such as term and specializations of these and of ph.
<spec-keyword> text<spec-data-1/><spec-data-2>...</spec-data-2> text<spec-data-1/><spec-data-2>...</spec-data-2> text<spec-data-1/><spec-data-2>...</spec-data-2> </spec-keyword>This cannot be validated with XML Schema or DTD because mixed content models are too lax.
Some elements such as keyword and term have a content model which does not allow further nesting of elements (discounting tm, which is not generic enough). Building such an element from multiple strings does not give the user a place to hang a conref.
Similarly, this problem can flow through to specializations, so that it is not possible to conref any text into a wintitle element.
<topic id="strings"> ... <body> <keyword><text id="productA">Product A</text></keyword> <keyword><text id="platformB">Platform B</text></keyword> <keyword id="AforB"><text><text conref="#strings/productA"/> for <text conref="#strings/platformB"/></text></keyword> </body> </topic> <topic> <title>Using <keyword conref="strings.xml#strings/AforB"/></title> ... </topic>
<!ELEMENT spec-keyword ((#PCDATA | spec-data-1 | spec-data-2)*)>By placing the text content inside a container element:
<spec-keyword> <text>text</text><spec-data-1/><spec-data-2>...</spec-data-2> <text>text</text><spec-data-1/><spec-data-2>...</spec-data-2> <text>text</text><spec-data-1/><spec-data-2>...</spec-data-2> </spec-keyword>validation can now be more strict:
<!ELEMENT spec-keyword ((text, spec-data-1, spec-data-2)*)>
The text element should also be added to the content model of ph so that text can be conreffed into a phrase without additional semantics.
<!ELEMENT text ((#PCDATA | text)*)>text contains all universal DITA attributes.
This element requires no addition to the architectural specification.
The text element associates no semantics with its content. It exists to serve as a container for text where a container is needed (e.g., for conref, or for restricted content models in specializations). Unlike ph, text cannot contain images. Unlike keyword, text does not imply keyword-like semantics. The text element contains only text data, or nested text elements. All universal attributes are available on text.
For contexts where ph is available, authors should use that element. Where keyword is available, authors should use that element. Where neither ph nor keyword is available, text can be used to pull content by conref.
Now that keyword is doing duty as a generic element for containing text, the langage specification for keyword should be modified to emphasize that a bare keyword implies no semantics.
DTDs and Schemas must be updated.
Implementations need to include processing for text. This may require implementations to handle XML fragments where they once needed to handle only strings. Fallback behaviour (flattening the XML a la xsl:value-of) is not appropriate for text if attributes like dir or translate or filtering properties are present. Flattening is also not appropriate for specializations of text.