#247 elements & attributes accidentally included in Tite 1.0

closed-fixed
Tite (10)
5
2011-09-18
2010-12-14
No

The following elements and attribute are currently in the Tite schema but not mentioned in the Tite prose documentation. According to Perry Trolard, they should be removed. He said this course of action was broadly affirmed in February 2010 by Dan, Laurent, and Lou.

I. ELEMENT
A. <biblScope>: Removing reduces complexity of schema. Need to be realistic about what's possible to do reliably at vendor
B. <measureGrp>: Mistakenly included in Tite.

II. ATTRIBUTE OR ATTRIBUTE CLASS: NOTES ON REMOVAL
A. @decls: Its purpose is to coordinate with the header, but Tite has no header.
B. att.naming: It's too much to expect keyboarders to refer to canonical names or to discern roles, so remove:
1. @key and @ref from <author>, <docAuthor>, <docTitle>, <resp>, and <title>
2. @key, @ref, @nymRef from <name>
3. @key, @ref, @nymRef, @role from <pubPlace>
C. There's a desire to limit the ways to express quantities in dates, times, spans of text, and numbers by removing all EXCEPT:
1. @when, @from, and @to from <date> (that is, removing @period, @notBefore, @notAfter, @atLeast, @atMost, @source, @type, @calenar, @cert, @extent, @max, @min, @precision, @quantity, @resp, @scope, and @unit)
2. @when and @type from <time> (that is, removing @period, @notBefore, @notAfter, @from, @to, @atLeast, @atMost, @max, @min, @precision, @quantity, @extent, @scope, and @unit)
3. @extent and @reason from <gap> and <unclear> (that is, removing @atLeast, @atMost, @source, @max, @min, @quantity, @unit, @precision, and @scope)
4. @type from <num> (that is, removing @atLeast, @atMost, @min, @max, and @value)
D. @ed should be removed from <cb>, <cols>, <milestone>, and <pb>: Vendor won't know about differences between editions.
E. @ref: When adding <g> before the release of 1.0, it was decided that it would be used without reference to a <glyph> and without attributes, so it's unneeded.
F. Other attributes to be removed to reduce encoding complexity or because their use would be inappropriate for a keyboarder at a vendor:
1. @type from <abbr>, <ab>, <cite>, <pb>, <q>, and <stage>
2. @role from <cell>
3. @version from <desc>
4. @place from <figure>
5. @notation from <formula>
6. @part from <ab> and <l>
7. @who from <q>
8. @width, @height, and @scale on <graphic>
9. @cert, @resp, @anchored, and @targetEnd from <note>
10. @evaluate and @cRef from <ptr> and <ref>

Discussion

  • Kevin Hawkins

    Kevin Hawkins - 2010-12-14

    I.C. <relatedItem>: Mistakenly included in Tite.

     
  • Lou Burnard

    Lou Burnard - 2010-12-14

    Redeclaring the ODD for Tite to use explicit inclusion of elements (rather than deletion) would be a good way of ensuring against future unintended inclusions. This was not possible when Tite was first defined, of course, but I would recommend using it now.

     
  • Paul Schaffner

    Paul Schaffner - 2010-12-16

    As you know, Kevin, we do not currently use Tite, but our
    TCP (and preceding) schemes were, as I understand it, part
    of the basis, or at least the background, for Tite. On
    those grounds, I'd point out ...

    (1) that @role on <cell> (and on <row>) is very handy,
    almost essential in capturing tables. It is the
    best way to capture the basic distinction between
    a data cell and a heading cell (or row), i.e. between
    an HTML <td> and <th>. It is well within the capability
    of keying vendors to make this distinction most
    of the time.

    (We also use @role="total" on cells and rows to
    denote cells in arithmetical tables that contain
    totals (sums), subtotals, products, etc., and are
    often distinctively rendered and should be
    distinctively displayed. This too is very useful.)

    (2) that @resp on <gap> and <unclear> serves to distinguish
    omissions (e.g. because of illegibility) made by
    the keying vendor from those made by the inhouse
    editors. The former are presumably more likely to
    be subject to further review, so it is a distinction
    worth preserving, at least in some version of the
    schema. (You don't mention @resp as being among those
    either removed or retained, so I do not know its
    status.)

    (3) that you'll need some way to distinguish (at least)
    in-line <figure>s from 'block' <figure>s of various
    kinds. With @place removed, you're left accomplishing
    this with @rend. That is how we do it, in fact, but is
    is your intention to load @rend that way?

    (4) that though we've used @extent on <gap> rather than
    @unit/@quantity, we've been told that the latter would
    have been a better choice: easier to process, at least.
    Was the decision in favor of @extent an advised one?

    That's all. The rest of the omissions would not affect us.

    pfs

     
  • David Sewell

    David Sewell - 2010-12-17

    We have used cell/@role and q/@type as part of TEI Tite-based vendor conversion specs.

    -- David Sewell, U of Virginia

     
  • Kevin Hawkins

    Kevin Hawkins - 2011-02-03

    In case it wasn't clear, my previous comment lists one more element (<relatedItem>) to remove from Tite. We missed this in the previous list.

    In my opinion based on comments above, the following should be retained in Tite (that is, excluded from the list of things to remove):

    a) cell/@role (for the reasons Paul lists)
    b) q/@type (to distinguish block and inline quotations, I assume)

    Paul Schaffner argues for gap@resp and unclear@resp, but this assumes that both the vendor and in-house editors use the same schema. It seems to me that Tite is designed only for use by vendors, so in-house staff would use a slightly looser schema that includes things like gap@resp and unclear@resp. Therefore, I don't think we need to retain @resp on either of these elements.

    Paul also comments on use of @extent vs. use of both @unit and @quantity on <gap>. Tite includes gap@unit and gap@quantity, which he says is the generally advised way to do things, so I don't see any reason for us to object to getting rid of gap@extent.

    It seems that Apex is not currently distinguishing between phrase-level (in-line) and chunk-level (block) <figure>s. I welcome thoughts from others on whether we should retain figure@place in Tite to indicate this (for any vendor that might want to do so), or whether we should leave figure@rend for this.

    I think we can all agree with Lou on rewriting the Tite ODD as he describes.

     
  • Kevin Hawkins

    Kevin Hawkins - 2011-02-21

    Hearing no objections from Council, consider this adopted. We'll plan to use figure@rend instead of figure@place since no one suggested an alternative.

    The ODD should be rewritten to exclude rather than delete elements. In addition to excluding whatever elements are deleted in the current Tite ODD, the following should be excluded:

    I. ELEMENT
    A. <biblScope>
    B. <measureGrp>
    C. <relatedItem>

    II. ATTRIBUTE OR ATTRIBUTE CLASS: NOTES ON REMOVAL
    A. @decls: Its purpose is to coordinate with the header, but Tite has no header.
    B. att.naming: It's too much to expect keyboarders to refer to canonical names or to discern roles, so remove:
    1. @key and @ref from <author>, <docAuthor>, <docTitle>, <resp>, and <title>
    2. @key, @ref, @nymRef from <name>
    3. @key, @ref, @nymRef, @role from <pubPlace>
    C. There's a desire to limit the ways to express quantities in dates, times, spans of text, and numbers by removing all EXCEPT:
    1. @when, @from, and @to from <date> (that is, removing @period, @notBefore, @notAfter, @atLeast, @atMost, @source, @type, @calenar, @cert, @extent, @max, @min, @precision, @quantity, @resp, @scope, and @unit)
    2. @when and @type from <time> (that is, removing @period, @notBefore, @notAfter, @from, @to, @atLeast, @atMost, @max, @min, @precision, @quantity, @extent, @scope, and @unit)
    3. @extent and @reason from <gap> and <unclear> (that is, removing @atLeast, @atMost, @source, @max, @min, @quantity, @unit, @precision, and @scope)
    4. @type from <num> (that is, removing @atLeast, @atMost, @min, @max, and @value)
    D. @ed should be removed from <cb>, <cols>, <milestone>, and <pb>: Vendor won't know about differences between editions.
    E. @ref: When adding <g> before the release of 1.0, it was decided that it would be used without reference to a <glyph> and without attributes, so it's unneeded.
    F. Other attributes to be removed to reduce encoding complexity or because their use would be inappropriate for a keyboarder at a vendor:
    1. @type from <abbr>, <ab>, <cite>, <pb>, and <stage>
    2. @version from <desc>
    3. @place from <figure>
    4. @notation from <formula>
    5. @part from <ab> and <l>
    6. @who from <q>
    7. @width, @height, and @scale on <graphic>
    8. @cert, @resp, @anchored, and @targetEnd from <note>
    9. @evaluate and @cRef from <ptr> and <ref>

     
  • Kevin Hawkins

    Kevin Hawkins - 2011-02-23

    In my last comment, "The ODD should be rewritten to exclude rather than delete elements." should read "The ODD should be rewritten to INCLUDE rather than delete elements."

     
  • Kevin Hawkins

    Kevin Hawkins - 2011-03-20

    Lou has rewritten the ODD to include rather than delete elements: see P5/Test/testtite.odd. This file, not P5/Exemplars/tei_tite.odd, should be further editing for this and other pending tickets until the Test version is merged into the Exemplars version.

     
  • Lou Burnard

    Lou Burnard - 2011-03-20

    Correction -- the file to work on is P5/Exemplars/tei_tite.odd -- the Test version is a temporary one only.

     
  • Perry Trolard

    Perry Trolard - 2011-04-15

    Just submitted r8811, which implements the list given by Kevin below on 2011-02-21.

     
  • Kevin Hawkins

    Kevin Hawkins - 2011-09-18
    • status: open --> open-fixed
     
  • Kevin Hawkins

    Kevin Hawkins - 2011-09-18
    • status: open-fixed --> closed-fixed