2.3.1 The Interface Fault
Component
A fault is an event that occurs during
the execution of a message exchange that disrupts the normal flow
of messages.
A fault is typically raised when a party
is unable to communicate an error condition inside the normal
message flow, or a party wishes to terminate a message exchange. A
fault message may be used to communicate out of band information
such as the reason for the error, the origin of the fault, as well
as other informal diagnostics such as a program stack
trace.
An Interface Fault component describes a fault that MAY
deleted text: be occur during execution invocation of an operation of the interface. The
Interface Fault component declares a
an abstract fault by naming it and
indicating the content or payload
contents of the fault message. When
and how the fault message flows is indicated by the Interface
Operation component 2.4 Interface
Operation .
The deleted text: reason the Interface Fault component deleted text: is a
property of the Interface component is because that provides
a convenient clear mechanism to declare
a name and describe the set of
fault message types and then indicate
which faults an interface may
generate. This allows operations deleted text: use those
types, thus allowing one to easily indicate that identify the
individual faults they may generate by name. This mechanism allows
the ready identification of the same fault message type can occur occurring across multiple operations and
referenced in multiple operations. bindings as
well as reducing duplication of description for an individual
fault.
Note that faults other than the ones
described in the Interface component can also be generated at
run-time, i.e. faults are an open set.
The properties of the Interface Fault component are as
follows:
If a deleted text: non-XML type system NOT
based on the XML Infoset [ XML Information
Set ] is in use (as
considered in <a href=
"#other-types"> 3.2 Using Other
Schema Languages ) then additional properties would need to
be added to the Fault Component (along with extensibility
attributes to its XML representation) to allow associating such
message types with the message reference.
For each Interface Fault component in the {faults} property of
an Interface component, the combination of {name} and {target
namespace} properties must be unique.
Interface Fault components are local to Interface components;
they cannot be referred to by QName, despite having both {name} and
{target namespace} properties. That is, two Interface components
sharing the same {target namespace} property but with different
{name} properties MAY contain Interface Fault components which
share the same {name} property. Thus, the {name} and {target
namespace} properties of the Interface Fault components are not
sufficient to form the unique identity of an Interface Fault
component. To uniquely identify an Interface Fault component one
must first identify the Interface component (by QName) and then
identify the Interface Fault within that Interface component (by a
further QName).
In cases where, due to an interface extending one or more other
interfaces, two or more Interface Faults components have the same
value for their {name} and {target namespace} properties, then the
component models of those Interface Fault components MUST be
equivalent (see 2.15 2.16
Equivalence of Components ). If the Interface Fault
components are equivalent then they are considered to collapse into
a single component. It is an error if two Interface Fault
components have the same value for their {name} and {target
namespace} properties but are not equivalent.
Note that, due to the above rules, if two interfaces that have
the same value for their {target namespace} property also have one
or more faults that have the same value for their {name} property
then those two interfaces cannot both form part of the derivation
chain of a derived interface unless those faults are the same
fault.
Note:
For the above reason, it is considered good practice to ensure,
where necessary, that the {name} property of Interface Fault
components within a namespace are unique, thus allowing such
derivation to occur without inadvertent error.
2.3.2 XML Representation of Interface Fault Component
<definitions>
<interface>
<fault
name="xs:NCName"
element="xs:QName"? >
<documentation />?
[ <feature /> | <property /> ]*
</fault>
</interface>
</definitions>
The XML representation for an Interface Fault component is an
element information item with the following Infoset
properties:
-
A [local name] of fault
-
A [namespace name] of "http://www.w3.org/2004/03/wsdl" "http://www.w3.org/2004/08/wsdl"
-
Two or more attribute information item s amongst its
[attributes] as follows:
-
Zero or more element information item amongst its
[children], in order, as follows:
-
An OPTIONAL documentation element information
item (see 5.
Documentation ).
-
Zero or more element information
item s from among the following,
in any order:
2.3.2.1 name
attribute information item with fault
[owner]
The name attribute information item
identifies a given fault element information
item inside a given interface element
information item .
The name attribute information item has
the following Infoset properties:
The type of the name attribute information
item is xs:NCName .
2.3.2.2 element
attribute information item with fault
[owner]
The element attribute information item
refers, by QName, to an element declaration component.
The element attribute information item has
the following Infoset properties:
The type of the element attribute information
item is xs:QName .