#298 att.editLike should not bring att.dimensions & att.ranging

GREEN
open-accepted
Martin Holmes
5(default)
2013-11-28
2011-04-22
BODARD Gabriel
No

As a result of the att.editLike attribute class containing both att.dimensions and att.ranging, a large number of elements which do not really have numerical values or content that needs to be expressed as numerical values, are acquiring attributes such as @atLeast, @atMost, @min, @max, @quantity, @extent, @precision. To my mind, the following elements should not have these attributes (for what on earth would they mean?):

add; del; addSpan; delSpan; restore; subst; corr; reg; unclear; expan; origPlace; origin; ex; am; supplied; surplus; orgName; persName; placeName; affiliation; climate; event; faith; langKnowledge; langKnown; location; nationality; occupation; org; person; place; relation; residence; sex; socecStatus; terrain.

How to fix this requires some discussion, however, since there are several elements (gap, space, date, time, origDate, age, birth, death, floruit, population, state, trait) which inherit these attributes and arguably should do so.

Discussion

1 2 > >> (Page 1 of 2)
  • BODARD Gabriel
    BODARD Gabriel
    2011-09-29

    • summary: att.editLike should not bring att.dimensions & att.editLike --> att.editLike should not bring att.dimensions & att.ranging
     
  • BODARD Gabriel
    BODARD Gabriel
    2012-03-20

    Presumbly the solution to this is (1) to remove att.dimensions and att.ranging from att.editLike, and (2) add them instead to those specific elements to which we think they belong. Any objections?

    My suggested list above should probably be discussed in some detail at the next F2F, to make sure I'm not missing anything obvious.

     
  • Lou Burnard
    Lou Burnard
    2012-04-17

    Agreed that these elements need to be re-classified.

     
  • Lou Burnard
    Lou Burnard
    2012-04-17

    • milestone: 871207 --> AMBER
    • assigned_to: nobody --> rahtz
    • status: open --> open-accepted
     
  • James Cummings
    James Cummings
    2012-09-19

    Gaby agrees to submit a more detailed proposal.

     
  • James Cummings
    James Cummings
    2012-09-19

    • assigned_to: rahtz --> gabrielbodard
     
  • BODARD Gabriel
    BODARD Gabriel
    2013-06-18

    Concretely, I propose that we:

    • remove att.dimensions from att.editLike
    • add att.dimensions to the elements gap, date, time, origDate, age, birth, death, floruit, population, state, trait which previously inherited it from att.editLike, so that they continue to have the attributes available.
    • also add att.dimensions to space for consistency with the above.

    This will have the effect that the following elements no long inherit att.dimensions, but I assert that they never should have in the first place: corr, reg, unclear, name, expan, origPlace, origin, ex, am, supplied, surplus, orgName, persName, placeName, geogName, affiliation, climate, education, event, faith, langKnowledge, langKnown, location, nationality, occupation, org, person, place, relation, residence, sex, socecStatus, terrain.

    If there are any elements in the latter list that anyone strongly feeds should inherit att.dimensions, we can add them as per the steps above. Any objection? Should we canvass for anyone this change would hurt, before making it?

     
    Last edit: BODARD Gabriel 2013-06-18
  • Martin Holmes
    Martin Holmes
    2013-06-18

    I think the change is good, but it would be worth running it by TEI-L
    just to be sure no-one will get bitten by it. I can imagine (for
    instance) someone using @precision on <population>.

    Cheers,
    Martin

    --
    Martin Holmes
    University of Victoria Humanities Computing and Media Centre
    (mholmes@uvic.ca)

     
    Last edit: BODARD Gabriel 2013-06-18
  • BODARD Gabriel
    BODARD Gabriel
    2013-06-18

    Yes, <population> is one of the elements I propose continuing to allow att.dimensions on, not losing it. The rationale being you would expect the content of this element to have a numerical component. I can't envisage such a component on the elements in the second list. (But you may be right that a message to TEI-L wouldn't hurt.)

     
  • In my opinion, @dimensions make sense on transcriptional elements, such as <add>, <delSpan> or <surplus>, etc. to encode the size of the affected text span in a convenient manner. I actually use @unit ('word' or 'chars') and @quantity on <surplus> in the Quest of the Holy Grail digital edition (http://txm.ish-lyon.cnrs.fr/txm/) to generate notes like "3 mots répétés" when appropriate.
    Of course, this is redundant, as the information can be calculated by analyzing the number of characters or word tokens inside <surplus> but removing these attributes will make my work much harder.

     
1 2 > >> (Page 1 of 2)