And what about Repair?

Take into account the case where the input is not understood at all.

The last two examples involve defining a lot of states and transitions. Yet note again that they do not take into account the case where the input is not understood at all. In order to do that, we could first implement the first method we saw in Section ``Grounding Extension 1''. That is, adding a transition to return to the state before the corresponding question if the input is not understood.

Even this combination of methods would not allow the user to correct the input directly after the request for confirmation. If the information gathered by the system is inadequate, the user has to go through answering all questions again. Instead it would be nice to allow for more targeted corrections by the user, for example corrections like:

	...
System:	So, you want a weather forecast for Stuttgart for tomorrow afternoon.
User:	No, I said Saarbrücken.
System:	So, you want a weather forecast for Saarbrücken for tomorrow afternoon.

Or:

	...
System:	So, you want a weather forecast for Saarbrücken for tomorrow morning.
User:	Wrong time.
System:	So, you want a weather forecast for Saarbrücken for tomorrow afternoon.
System:	OK, For when?
	...

To allow for this kind of dialogues, we have to add still more states and transitions, to distinguish between different kinds of user-reactions to the system's confirmation request and repeat different questions based on what recognition errors the user points out.

?- Question!

What about including insertions, for example clarification sub-dialogues, and still allowing for grounding within them in the manner described above?