proposal for a floating div

proposal for a floating div

14 March 2012

To: TEI Council

From: Julia Flanders, Martin Mueller, Paul Schaffner

Re: floating div

We recommend the addition of a "floating div" element to the current set of elements. It should be able to occur wherever a <p> element can occur. Its content model should be maximally that of a <div> that can contain other divs and minimally that of a div7. All of us prefer the former, but some would settle for the latter. We are agnostic about the exact name for such an element. We are sending this proposal to the TEI-list at large in the hope that it may prompt helpful responses from others.

The Council needs no reminder that this issue has often been discussed. The addition of <floatingText> to the element set of P5 addressed some of the concerns leading to those discussions, but raised others. The Guidelines define <floatingText> as an element that "contains a single text of any kind, whether unitary or composite, which interrupts the text containing it at any point and after which the surrounding text resumes." The fuller discussion of <floatingText> describes it as a device for dealing with the fact that texts do not always "tesselate" without remainder. Paul has used the metaphor of "raisins in the oatmeal" to describe the encoding problems that arise when you want to distinguish the integrity of textual raisins of varying size and shape from the surrounding oatmeal.

A surprising number of 'raisins' can be preserved by (ab)using the <q> element and taking very literally its definition as "material which is marked as (ostensibly) being somehow different than the surrounding text, for any one of a variety of reasons" while ignoring the widely ignored parenthetical remark that the content of <q> is "separated from the surrounding text with quotation marks." Paul estimates that 95% of "raisin problems" in EEBO and ECCO texts would go away if <head> could be a child of <q>.

Broadly speaking, the problem of interrupted tesselation is similar to that of escape characters in programming languages. You want something that the machine can handle and that is easy on human eyes and hands. From that perspective, <floatingText> is too much for many purposes. Why wrap paragraphs in two elements (floatingText/body) when one will do?

There is a second consideration. The formal definition of <floatingText> is purely syntactic. In correspondence arising from last year's Council meeting Kevin wrote:

It is important to distinguish the use of <floatingText> and <quote>. Whereas the semantics of <quote> imply that its content emanates from somewhere external to the current text, <floatingText> does not imply 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. Such an "inclusion" might consist of a text that is perceived as external to the document, such as a letter, enclosure, or attachment, but it might equally well be a text that is not external to the document, such as the text of a "musical number" that is clearly set off from its surrounding text in the libretto of an opera.

The two elements may be used in combination: a <floatingText> may appear within a <quote> (when a text with rich internal structure is quoted at length), and <floatingText> may also include one or more <quote> elements as part of its own structure, just like any text.

Or as Laurent put it more briefly "floatingText are sub-texts whose internal structure does not match that of the encompassing document."

On the other hand, the names of the elements (text, body) and the double wrapper suggest that <floatingText> is a weighty matter. As Paul put it in the recent discussion about <epigraph>, <lg> and <head>

this example is just another example of that murky middle ground 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: a category that continues to generate suggestions ("add <head> to <q>"; "create a "<floatingDiv>" tag; etc.), one of which may eventually enter TEI, but all of would inevitably cause border disputes with the existing tag set.

One way of resolving the border disputes would be to say "use the simplest escape element that will do." If what you need to "escape" can be put inside <floatDiv>, use that. If you need more use <floatingText>.

Re: proposal for a floating div

to ensure this comes up for discussion at the Council's upcoming
face-to-face meeting in Ann Arbor. (If others have substantial
bugs or complex feature requests adding them within the next week
would be recommended.)

However, I would encourage discussion of this topic to continue
here on TEI-L as I know this is a subject that has been discussed
before and we would like to get the broadest range of input possible.

Many thanks,

-James

On 14/03/12 20:18, Martin Mueller wrote:

> 14 March 2012
>
> To: TEI Council
>
> From: Julia Flanders, Martin Mueller, Paul Schaffner
>
> Re: floating div
>
> We recommend the addition of a "floating div" element to the
> current set of elements. It should be able to occur wherever a
> <p> element can occur. Its content model should be maximally that
> of a <div> that can contain other divs and minimally that of a
> div7. All of us prefer the former, but some would settle for the
> latter. We are agnostic about the exact name for such an element.
> We are sending this proposal to the TEI-list at large in the hope
> that it may prompt helpful responses from others.
>
> The Council needs no reminder that this issue has often been
> discussed. The addition of <floatingText> to the element set of
> P5 addressed some of the concerns leading to those discussions,
> but raised others. The Guidelines define <floatingText> as an
> element that "contains a single text of any kind, whether unitary
> or composite, which interrupts the text containing it at any
> point and after which the surrounding text resumes." The fuller
> discussion of <floatingText> describes it as a device for dealing
> with the fact that texts do not always "tesselate" without
> remainder. Paul has used the metaphor of "raisins in the oatmeal"
> to describe the encoding problems that arise when you want to
> distinguish the integrity of textual raisins of varying size and
> shape from the surrounding oatmeal.
>
> A surprising number of 'raisins' can be preserved by (ab)using
> the <q> element and taking very literally its definition as
> "material which is marked as (ostensibly) being somehow different
> than the surrounding text, for any one of a variety of reasons"
> while ignoring the widely ignored parenthetical remark that the
> content of <q> is "separated from the surrounding text with
> quotation marks." Paul estimates that 95% of "raisin problems" in
> EEBO and ECCO texts would go away if <head> could be a child of <q>.
>
> Broadly speaking, the problem of interrupted tesselation is
> similar to that of escape characters in programming languages.
> You want something that the machine can handle and that is easy
> on human eyes and hands. From that perspective, <floatingText> is
> too much for many purposes. Why wrap paragraphs in two elements
> (floatingText/body) when one will do?
>
> There is a second consideration. The formal definition of
> <floatingText> is purely syntactic. In correspondence arising
> from last year's Council meeting Kevin wrote:
>
> It is important to distinguish the use of <floatingText> and
> <quote>. Whereas the semantics of <quote> imply that its
> content emanates from somewhere external to the current text,
> <floatingText> does not imply 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. Such an "inclusion" might consist of a text that is
> perceived as external to the document, such as a letter,
> enclosure, or attachment, but it might equally well be a text
> that is not external to the document, such as the text of a
> "musical number" that is clearly set off from its surrounding
> text in the libretto of an opera.
>
> The two elements may be used in combination: a <floatingText>
> may appear within a <quote> (when a text with rich internal
> structure is quoted at length), and <floatingText> may also
> include one or more <quote> elements as part of its own
> structure, just like any text.
>
>
> Or as Laurent put it more briefly "floatingText are sub-texts
> whose internal structure does not match that of the encompassing
> document."
>
> On the other hand, the names of the elements (text, body) and the
> double wrapper suggest that <floatingText> is a weighty matter.
> As Paul put it in the recent discussion about <epigraph>, <lg>
> and <head>
>
> this example is just another example of that murky middle
> ground 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: a
> category that continues to generate suggestions ("add <head>
> to <q>"; "create a "<floatingDiv>" tag; etc.), one of which
> may eventually enter TEI, but all of would inevitably cause
> border disputes with the existing tag set.
>
>
> One way of resolving the border disputes would be to say "use the
> simplest escape element that will do." If what you need to
> "escape" can be put inside <floatDiv>, use that. If you need more
> use <floatingText>.
>

--
Dr James Cummings, InfoDev,
Computing Services, University of Oxford

Re: proposal for a floating div

The TEI Technical Council discussed the <floatingDiv> proposal
http://purl.org/tei/fr/3504690 at its last face to face meeting.
After much wide ranging discussion and many examples by one of
the submitters of the proposal (Paul Schaffner), the consensus
which emerged was that the examples presented could be dealt with
by other existing means. It was felt that the need to use
floatingText/body did not present a significant encoding burden
for the textual phenomenon discussed. The Technical Council also
noted that the specific case of drama could now be handled by
<spGrp>. The Technical Council found it hard to identify a
distinct use case where the proposed <floatingDiv> would be more
appropriate than (or distinguishable from) the existing
<floatingText> element. This may also be because the prose
describing <floatingText> has been relaxed from its first
inception in P5 ver 1.0.0 and also its relationship with quote
has since been clarified.

The TEI Technical Council is willing to continue to consider this
matter but requires:

* A clear categorisation of how to distinguish between
<floatingText> and the proposed <floatingDiv>

* More examples of proposed <floatingDiv> candidates which are
not adequately marked up using <floatingText> or <spGrp>

The Technical Council requests that any further remarks
concerning the proposed <floatingDiv> element be added to the
http://purl.org/tei/fr/3504690 SourceForge ticket for ease of
discussion.

TEI Technical Council

On 14/03/12 21:48, James Cummings wrote:

> Hi Martin,
>
> Thanks for this proposal. I have added a sourceforge feature
> request ticket in at:
>
> http://purl.org/tei/fr/3504690>
> to ensure this comes up for discussion at the Council's upcoming
> face-to-face meeting in Ann Arbor. (If others have substantial
> bugs or complex feature requests adding them within the next week
> would be recommended.)
>
> However, I would encourage discussion of this topic to continue
> here on TEI-L as I know this is a subject that has been discussed
> before and we would like to get the broadest range of input
> possible.
>
> Many thanks,
>
> -James
>
>
> On 14/03/12 20:18, Martin Mueller wrote:
>> 14 March 2012
>>
>> To: TEI Council
>>
>> From: Julia Flanders, Martin Mueller, Paul Schaffner
>>
>> Re: floating div
>>
>> We recommend the addition of a "floating div" element to the
>> current set of elements. It should be able to occur wherever a
>> <p> element can occur. Its content model should be maximally that
>> of a <div> that can contain other divs and minimally that of a
>> div7. All of us prefer the former, but some would settle for the
>> latter. We are agnostic about the exact name for such an element.
>> We are sending this proposal to the TEI-list at large in the hope
>> that it may prompt helpful responses from others.
>>
>> The Council needs no reminder that this issue has often been
>> discussed. The addition of <floatingText> to the element set of
>> P5 addressed some of the concerns leading to those discussions,
>> but raised others. The Guidelines define <floatingText> as an
>> element that "contains a single text of any kind, whether unitary
>> or composite, which interrupts the text containing it at any
>> point and after which the surrounding text resumes." The fuller
>> discussion of <floatingText> describes it as a device for dealing
>> with the fact that texts do not always "tesselate" without
>> remainder. Paul has used the metaphor of "raisins in the oatmeal"
>> to describe the encoding problems that arise when you want to
>> distinguish the integrity of textual raisins of varying size and
>> shape from the surrounding oatmeal.
>>
>> A surprising number of 'raisins' can be preserved by (ab)using
>> the <q> element and taking very literally its definition as
>> "material which is marked as (ostensibly) being somehow different
>> than the surrounding text, for any one of a variety of reasons"
>> while ignoring the widely ignored parenthetical remark that the
>> content of <q> is "separated from the surrounding text with
>> quotation marks." Paul estimates that 95% of "raisin problems" in
>> EEBO and ECCO texts would go away if <head> could be a child of
>> <q>.
>>
>> Broadly speaking, the problem of interrupted tesselation is
>> similar to that of escape characters in programming languages.
>> You want something that the machine can handle and that is easy
>> on human eyes and hands. From that perspective, <floatingText> is
>> too much for many purposes. Why wrap paragraphs in two elements
>> (floatingText/body) when one will do?
>>
>> There is a second consideration. The formal definition of
>> <floatingText> is purely syntactic. In correspondence arising
>> from last year's Council meeting Kevin wrote:
>>
>> It is important to distinguish the use of <floatingText> and
>> <quote>. Whereas the semantics of <quote> imply that its
>> content emanates from somewhere external to the current text,
>> <floatingText> does not imply 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. Such an "inclusion" might consist of a text that is
>> perceived as external to the document, such as a letter,
>> enclosure, or attachment, but it might equally well be a text
>> that is not external to the document, such as the text of a
>> "musical number" that is clearly set off from its surrounding
>> text in the libretto of an opera.
>>
>> The two elements may be used in combination: a <floatingText>
>> may appear within a <quote> (when a text with rich internal
>> structure is quoted at length), and <floatingText> may also
>> include one or more <quote> elements as part of its own
>> structure, just like any text.
>>
>>
>> Or as Laurent put it more briefly "floatingText are sub-texts
>> whose internal structure does not match that of the encompassing
>> document."
>>
>> On the other hand, the names of the elements (text, body) and the
>> double wrapper suggest that <floatingText> is a weighty matter.
>> As Paul put it in the recent discussion about <epigraph>, <lg>
>> and <head>
>>
>> this example is just another example of that murky middle
>> ground 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: a
>> category that continues to generate suggestions ("add <head>
>> to <q>"; "create a "<floatingDiv>" tag; etc.), one of which
>> may eventually enter TEI, but all of would inevitably cause
>> border disputes with the existing tag set.
>>
>>
>> One way of resolving the border disputes would be to say "use the
>> simplest escape element that will do." If what you need to
>> "escape" can be put inside <floatDiv>, use that. If you need more
>> use <floatingText>.
>>
>
>