Proposal for floatingDiv as posted to TEI-L by Martin Mueller at:
Comment by Linda Patrik on TEI-L:
"Thank you for returning to the issue of a text embedded within the main text in a way that <q> and even <div> can't handle easily. A couple years ago I mentioned the problem of encoding the texts of the Tibetan canon, which have two species of "raisins" in the oatmeal text: inserted, complete verses from the older, root text (external text or floating text) and interwoven, quoted, partial phrases from the root text.
The first species is like the nesting of boxes within one another. Each box has its own completeness. For example, there is an orderly sequence of verses of the root text, e.g., Fundamental Wisdom of the Middle Way by the 2nd century philosopher Nagarjuna, quoted in later, nested commentaries that follow the same sequence of verses. Each of Nagarjuna's verses is commented upon by the 7th century philosopher Chandrakirti for a page or two; then each of Chandrakirti's comments are nested within the longer text of the 16th century Tibetan philosopher Mikyo Dorje and commented upon by him. And so on.
The second species is more like melting chunks of butter in the oatmeal: certain words or phrases from Nagarjuna's verses--usually incomplete sentences--are mingled with Chandrakirti's own words to create complete sentences in Chandrakirti's commentary. The same strategy is used by Mikyo Dorje, who mingles either Nagarjuna's words or Chandrakirti's words with his own to create complete sentences in his commentary.
If you can, could you please add this complex structural device of Tibetan texts to your discussion of floating text?"
I believe the issue discussed by Julia Flanders, Martin Mueller and Paul Schaffner is a symtom of something deeper.
TEI inherits from Unicode an explicit linearity assumption. I believe that we need a tag that explicitly breaks this assumption, in much the same way that we have the glyph tag to break the countable-set-of-fixed-characters assumption. Maybe these semantics can be explicitly assigned to an existing tag, maybe it's a new tag, I don't know.
After reading it again, and after today's brief discussion, I find the following aspects of Martin's proposal unconvincing:
He suggests that <floatingText> will not do because "Why wrap paragraphs in two elements (floatingText/body) when one will do?" I think the additional penalty of <body><div></div></body> is trivial.
He says that "The formal definition of <floatingText> is purely syntactic." I'm not sure I really understand what that means, but the quote from Kevin that supports it includes this: "The <floatingText> element is simply used whenever the richer content model it provides is required to support mark up of a text or part of a text which presented as a discrete inclusion within the text." This seems to me to be basically what he's looking for in <floatingDiv>.
Finally, he says "the names of the elements (text, body) and the double wrapper suggest that <floatingText> is a weighty matter, and quotes Paul's description of "headed, floating, discrete textual objects that seem too small to qualify as <text>s and possessed of too much integrity to be mere line groups or paragraphs". I don't really know why anything would be too small to qualify as a <text> -- inscriptions are texts, haikus are texts, and there are lots of other tiny examples of texts.
So I think we could expand and clarify the explanation of <floatingText> to show that we think it is appropriate for use in the case of smaller embedded "raisins", and provide some examples in support.
Council has already sent this back to proposers asking for clearer use-cases which can't be required with thecurrent tagset, especially floatingText since the initial language about it has been loosened.
Council had previously rejected the floatingDiv proposal as it was, asking for new examples. PS provided three more examples:
but Council still did not find these more convincing than the earlier ones.
The Council generally agrees with the comment on the ticket to the effect that there is not enough convincing evidence for the need for <floatingDiv>, and will close the ticket pending any new concrete submissions.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.