I think the fault field should be used for both expected an unexpected faults. To me it seems like checked vs. unchecked exceptions. You can still catch the latter and see what kind of thing it is.
Gary - is there a hidden disadvantage to including both in the fault field that I'm not seeing? If not, then it seems clear that the advantage of being able to report on it is too great to pass up.
I wouldn't say there is a disadvantage, although it would be good to be able to understand which faults are checked and unchecked - just to understand which are associated with the service interface.
A couple of options exist:
1) Set the fault field to a generic reserved value to indicate that an unexpected fault occurred, and the details of the fault will be provided in the content field.
2) Try to set the fault to a meaningful value representing the unexpected fault, and set a property to reflect that it is unexpected.
The benefit of (1) from a graphical visualization perspective, is that all unexpected errors get grouped into a single segment of a pie/bar chart. If each possible unexpected exception is represented differently, then this could fragment the results, making it impossible to distinguish expected from unexpected in the chart.
The benefit of (2) is that the fault field conveys more meaning.
May be a compromise is that the fault field has a reserved value (e.g. ERROR), that won't conflict with actual fault values, and is also (hopefully) understandable in many languages. As already mentioned, the main exception description will be in the content. However if there is a 'type' associated with the unchecked fault, then it could be put into a property, allowing easier analysis by rules etc.?