In the spirit of real-time editing

Here's a more detailed proposal for faults.

General points:

    * Each of the fault detail elements here has open content.  You can
      always add more information if you want.
    * I don't know the best way (or ways) to indicate where an error
      occurred in a SOAP message, and this is a general issue, so I'm
      not going to advocate one.  You can always put your favorite
      location information in the open content.
    * Everything is optional.  If it's prohibitive to include the actual
      IRI that was malformed, don't do it.
    * for xsi:anyUri, read the appropriate type for IRI.

So, here are the fault detail elements:

    * Address is mandatory in EPR.  Detail element is empty by default,
      but (MAY include location information as above).
    * Address in EPR is not an IRI. Detail element contains an optional
      <wsa:BadIRI> child, type xsi:any, containing that which was not an
      IRI (it's any, not string, since the offending content might have
      been complex)
    * Action is mandatory in MAPs.  Detail element contains zero or more
      <wsa:RecognizedAction> elements, type xsi:anyUri, each of which is
      an action that the endpoint would have recognized.  Obviously,
      many endpoints will not wish to include such information even if
      it is readily available.
    * Source, reply, fault and message id max cardinality violated. 
      Detail element may include
          o Zero or more <wsa:Role> elements (unless there is a more
            generic name).  Type is xsi:anyUri.  Either entirely
            missing, or one for each role the endpoint was acting in. 
            This will help flush out situations where the receiver was
            acting in more roles than the sender expected.
          o Zero or more <wsa:MAPCardinality> elements.  Value is
            xsi:int, showing how many times the element occurred.  The
            required @wsa:property attribute is xsi:string one of
            "source endpoint", "reply endpoint", "fault endpoint" and
            "message id".
    * Destination, source, reply or fault endpoints not properly formed
      EPRs.  Detail may contain zero or more <wsa:BadEndpoint> elements,
      each of which has a required @wsa:property attribute as above
      (mutatis mutandis), which in turn has the content described for
      "address is mandatory in EPR" or "address EPR is not an IRI" above.
    * Message ID not unique.  Detail element may contain a
      <wsa:ReusedMessageID> element, type xsi:anyUri.  Value is the
      offending ID.
    * Action, message ID, relationship not well-formed IRI at all. 
      Detail contains zero or more <wsa:BadIRI> elements, @wsa:property
      attribute as appropriate, with the offending IRI.
    * Action, message ID, relationship not absolute IRI.  Detail
      contains zero or more <wsa:BadAbsoluteIRI> elements, otherwise
      just like the previous case.
    * Reply endpoint, message ID required in request message.  Detail
      contains zero or more <wsa:MissingProperty> elements, empty
      content, @wsa:property attribute as appropriate.