[tei-council] Grouping traitlike, statelike, and eventlike elements - ID: 3060867

[Piotr Bański]

May I ask the Council to have a look at a ticket that was set to pending
and this is probably why it didn't make it onto Lou's list (and I wasn't
nagged by SF even once about it):

http://sourceforge.net/tracker/index.php?func=detail&aid=3060867&group_id=106328&atid=644065

I thought the implementation would be as quick as Lou's summary of what
we decided in Paris, but things do not seem that easy (the schema
becomes non-deterministic), unless we decide to split the
not-so-easy-to-implement listState into listOrgState,
listPersState, and listPlaceState (listPlaceStateLike? OhMyGoodness...).

I summarised the way I see this in my recent comment on the ticket. If
this reasoning is found correct, the practical question for the Council
is: do I have green light to implement the three above-mentioned list
elements?

Or do we take a different route, for example the route proposed
tentatively by Sebastian (let me stress that he wrote in a hurry from
the airport and kept to the logic of the decision made in Paris):

> I think I'd 
> 
>  * make a class model.stateLike
>  * make trait a direct member of that
>  * make the other stateLike classes members of it too
>  * refer to stateLike in listState
> 
> does that work?
> 

which I think has the semantic problem of mixing three kinds of
stateLike elements (and thus making it possible to talk about the
climate of a person and the sex of a place).

Thanks,

  P.