#416 @age should allow numbers


@age is defined on <person> and <personGrp> separately. This seems a bit redundant, since the definitions are essentially identical.

person/@age suggests the following example values:

infant, child, teen, adult, and senior

then the example which actually uses the attribute has a completely different value, "mid":

<person sex="2" age="mid">
<p>Female respondent, well-educated, born in Shropshire UK, 12 Jan 1950, of unknown occupation. Speaks French fluently. Socio-Economic
status B2.</p>

The datatype for @age in both cases is data.enumerated, which is "a single XML name"; this has the side-effect of making it impossible to use integers. I think an attribute called "age" which doesn't allow you to put in the actual age as an integer is a bit ridiculous.

What I'd like to suggest is this:

1. We should consider an attribute class for the attributes which are shared by <person> and <personGrp> (@age, @sex and @role, although the last is slightly more problematic because there's an @role in att.naming which might overlap).

2. We should also consider a datatype for @age which allows enumerated values (infant, teen, etc.; teens, twenties, thirties, etc.) but also allows an integer value for the actual age of the person. It should probably allow floating-point numbers, actually -- <person id="AdrianMole" age="13.75"></person>.

Neither of these changes would break backward compatibility as far as I can tell. Although moving an attribute into a class might break some existing ODD files, it would not render any existing TEI documents invalid.

One thing I haven't figured out is how to have a datatype that allows both enumerated values and integers or floats.


  • James Cummings

    James Cummings - 2012-06-29
    • assigned_to: nobody --> louburnard
  • Lou Burnard

    Lou Burnard - 2012-07-05

    @age is obviously going to change over time and is therefore more reliably provided by looking at the <birth> element within <person> . Even Adrian Mole is not 13 3/4 in every book in which he appears. On <person>, @age was retained as a "broad brush" categorisation only, hence the suggested list of values. Maybe it should have been renamed to @ageGroup . The inconsistency between the example and the suggested values should certainly be corrected though.

  • Lou Burnard

    Lou Burnard - 2012-07-05
    • status: open --> open-wont-fix
  • Sebastian Rahtz

    Sebastian Rahtz - 2012-07-15

    It would be easy enough to support either numbers or periods, but really they should be different attributes, in the same way as we have @when and @period for events. Is there
    really a use for the exact-age-as-number scenario? what would it mean? Adrian Mole
    is such an outlier.... however, having values like "50s" "60s" and "30+" may be real, so
    the data type probably needs relaxing to data.word, and that would allow Adrian in too.

  • Lou Burnard

    Lou Burnard - 2012-09-16
    • milestone: --> 871214
  • Lou Burnard

    Lou Burnard - 2012-09-16

    I fear the potential for confusion if we allow numeric values for @age (with the meaning of "agegroup" which is the only one that makes sense). So I plan to either do nothing or rename this attribute as ageRange (possibly delivering it by class, along with @sex and other coded attributes of a person e.g. social status?)

  • Lou Burnard

    Lou Burnard - 2012-09-16

    At rev 10818 made examples consistent with suggested valList

  • Lou Burnard

    Lou Burnard - 2012-09-16
    • milestone: 871214 --> GREEN
    • status: open-wont-fix --> closed-wont-fix