OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 1.2 Feature Suggestion: <text> element


At least with DITA 1.1, where we can't add attributes, a reasonably 
common pattern is this (using the base types, which would normally be 
specialized for a specific application):

<ph>
   <data/>
   <ph>Text content of the phrase</ph>
</ph>

as opposed to:

<ph>
   <data/>
   Text content of the phrase
</ph>

(That is, using a nested phrase to clearly separate the PCDATA content 
from the metadata and better control the order of occurrence of the text 
and the data.)

A typical specialization would be to name the nested "ph" element 
"text", indicating that its purpose is to contain the text content of 
the outer phrase:

<ph>
   <data/>
   <text>Text content of the phrase</text>
</ph>

Given the general utility of this pattern, it seems reasonable to 
provide the "text" specialization of "ph" as a base type so specializers 
don't have to repeatedly re-invent it.

Note that in neither DTDs nor schemas is it possible to prevent the 
occurrence of PCDATA content before or after a subelement of a given 
element, although in schemas you can control the order of subelements 
within an element with a "mixed" content model. This is one reason why 
using the "text" pattern is generally better than just allowing the text.

While from an abstract processing standpoint it shouldn't matter where 
the <data> elements go (their semantic doesn't change based on position 
and their existence shouldn't affect the processing of the base 
content), from an authoring standpoint it can be less confusing for 
authors to have clear markup rules (for example, authors don't have to 
worry about white space around the <data> elements). In addition, naive 
processors might assume, for example, that the <data> elements will be 
the first child node of their parents, which won't necessarily be the 
case without the "text" element (because a text node could precede the 
<data> element).

Cheers,

Eliot

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]