#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>
</person>
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.
@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.
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.
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?)
At rev 10818 made examples consistent with suggested valList