a general purpose <description> alongside traits/states

I have noticed general dissatisfaction with the distinction between trait and state, though it's clear enough. Introducing a third generic element, especially one with a name inviting confusion with all the other "desc" things in the TEI does not seem like a particularly good idea to me. Would it not be better to deprecate either trait or state (preferably the latter)?

I agree with Lou that (a) the distinction, while maybe not universally loved, is at least coherent, and (b) <trait> is a better name for a general element than <description>. If people don't like the distinction, could we not just encourage them to use <trait> for both essential and incidental(*) characteristics of persons, places, things?

(*) I think this is the better distinction than "temporary" vs "permanent", as some people seem to imagine it.

I'm inline with extending the use of trait as described. Examples should show how temporal constraints (attributes) may be used to move along the incidental/essential continuum.

Agreed that distinction is not always clear; probably state should be chosen as default; trait examples should be simplified; probably traitLike and stateLike classes should be merged (i.e. move existing model.traitLike elements into model.stateLike)

I see the tasks assigned as of 2011-11 Council meeting as:

1) Add prose to Guidelines indicating that where users have a hard time distinguishing between <state> and <trait> that they should use <state> (with @type attribute of course) as a default (on the principle that almost all states and traits in theory can be time-limited). If they do wish to differentiate between those things that are usually time-dependent or not, or 'intrinsic' / 'essential' then they can use both <state> and <trait>. Remarks on trait/state specs should indicate this.

2) All examples in the Guidelines of trait having date-related attributes should be rationalized. I.e. they should be changed to <state> where appropriate, or they should have the attributes removed. While dating attributes are allowed on <trait> by the schema we should indicate good practice in the examples by only having them on <state>. Remarks should be added to trait to indicate this.

3) the elements that claim membership of traitLike and stateLike classes be merged into only claiming membership stateLike and any content-models referring to traitLike alone updated to refer to stateLike alone because it is believed these two content models are used identically throughout. (However, this will be checked).

Anything I'm missing?

Committed as of revision 9854. model.*TraitLike removed entirely as it had no more elements and no independent use of its content model. ND chapter prose was tidied up to reflect this, but probably needs a more substantial overhaul at some point. In general, <description> was discarded as an idea and instead <state> chosen as the general purpose element. The distinction with <trait> was preserved but loosened. <trait> should now only be used for when you really are interested in classifying the differences between states and traits. Otherwise, state is the general purpose <description>'like element. The <state type="havingEyeColour"> style of type classification can be used to provide easy output to CIDOC, RDF, etc.