> > The use of attributes/elements is a trickier problem, I think we
> > really should use attributes for exactly the same reason SOAP is
using
> > elements, consistency with the overall coding style.
I don't mind attributes at all, but the SAML schema-24 as currently
written only permits a single subcode, because the subcode is a single
attribute of the top level Status element. If that's an artifact of the
recursion being deleted, that's fine, just mentioning it.
The way to keep the recursion and still use attributes is to have
something like this:
<simpleType name="StatusCodeEnumType">
<restriction base="QName">
<enumeration value="samlp:Success"/>
<enumeration value="samlp:VersionMismatch"/>
<enumeration value="samlp:Responder"/>
<enumeration value="samlp:Requester"/>
</restriction>
</simpleType>
<complexType name="StatusCodeType">
<sequence>
<element name="Subcode" type="samlp:SubStatusCodeType"
minOccurs="0"/>
</sequence>
<attribute name="Value" type="sampl:StatusCodeEnumType"
use="required"/>
</complexType>
<complexType name="SubStatusCodeType">
<sequence>
<element name="Code" type="samlp:SubStatusCodeType"
minOccurs="0"/>
</sequence>
<attribute name="Value" type="QName" use="required"/>
</complexType>
<complexType name="StatusType">
<sequence>
<element name="Code" type="samlp:StatusCodeType"/>
<element name="Message" type="string" minOccurs="0"
maxOccurs="unbounded"/>
<element name="Detail" type="anyType" minOccurs="0"/>
</sequence>
</complexType>
> > One issue that did occur to me is whether we should specify
> > which sub codes are permissible for which top level codes.
For the ones defined in the SAML spec, definitely. Obviously this is an
open-ended thing.
A given error condition code is defined by a sequence of QNames, rooted
in the SAML top-level codes, but by definition this isn't an exhaustive
list, and any status SAML defines can be "suffixed" with additional
detail.
This is no different than the SOAP 1.1 dotted notation, just XML-ized.
-- Scott
