There's no "right" way to represent something in XML, it depends on your application's context. In some contexts, it may be perfectly valid to have different data types for utterance_in_a_state_of_speechlessness and utterance_in_a_state_of_happiness. I may have two different classes for representing UtteranceInAStateOfSpeechlessness and UtteranceInAStateOfHappiness (both inheriting from the Utterance base class) with different attributes specific to each type of utterance, and want them to be deserialized from XML to the right class. Or I may want spechlessness utterances to initiate a process that attempts to resolve the speechlessness problem, while happiness utterances are simply logged in a database (for the purpose of generating a monthly report of hapiness utterances) and acknowledged.

Don't try to be too generic for your context, it would lead to:
<message>
    <event>Utterance</event>
    <eventParam name="state">Speechlessness</eventParam>
</message>,
which would be the XML equivalent of having a std::vector<void *> (a typed container that holds untyped values). If that's then submitted to a generic DoAnything web service, it would then mean your web service will contain code to route that message to the right place, instead of letting the programming language/web server/integration engine route the request to the right class/orchestration based on method name and data type.

It's fine to try to be as generic as possible, but the right balance between genericity and specificity is different from one context to another. So my idea of having two different data types for different states of utterances may just be additional overhead for some contexts, and then you would be right to have a generic Utterance class with a state and no subclasses.