- From: Martin Gudgin <marting@develop.com>
- Date: Wed, 7 Nov 2001 18:38:11 -0000
- To: "Rich Salz" <rsalz@zolera.com>
- Cc: "XML Protocol Discussion" <xml-dist-app@w3.org>
Thinking about it the flat approach some more, it turns out the schema that restricts the first value to a enumeration of QNames is impossible to write if all the siblings have the same name. This is because it is not legal in XML Schema to map the same element name in a given context to more than one type. Using one of the hierarchical approaches would fix this. Alternatively we could define a schema like this; <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:tns='http://www.w3.org/2001/09/soap-envelope' targetNamespace='http://www.w3.org/2001/09/soap-envelope' > <xs:simpleType name='faultcodeenum'> <xs:restriction base='xs:QName'> <xs:enumeration value='tns:DataEncodingUnknown' /> <xs:enumeration value='tns:MustUnderstand' /> <xs:enumeration value='tns:VersionMismatch' /> <xs:enumeration value='tns:Receiver' /> <xs:enumeration value='tns:Sender/> </xs:restriction> </xs:simpleType> <xs:complexType name='faultcodeType' > <xs:sequence> <xs:element name='value' type='tns:faultcodeenum' /> <xs:element name='sub' type='xsd:QName' minOccurs='0' maxOccurs='unbounded' /> </xs:sequence> </xs:complexType> </xs:schema> which gives an instance like; <faultcode> <value>soap:Reciever</value> <sub xmlns:app='http://example.org/apps' >app:SomeError</sub> </faultcode> The schema for the hierarchical approach ( the attribute form in this case ) would look like this ; <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:tns='http://www.w3.org/2001/09/soap-envelope' targetNamespace='http://www.w3.org/2001/09/soap-envelope' > <xs:simpleType name='faultcodeenum'> <xs:restriction base='xs:QName'> <xs:enumeration value='tns:DataEncodingUnknown' /> <xs:enumeration value='tns:MustUnderstand' /> <xs:enumeration value='tns:VersionMismatch' /> <xs:enumeration value='tns:Receiver' /> <xs:enumeration value='tns:Sender/> </xs:restriction> </xs:simpleType> <xs:complexType name='rootfaultcodeType' > <xs:sequence> <xs:element name='faultcode' type='tns:faultcodeType' minOccurs='0' /> </xs:sequence> <xs:attribute name='value' type='tns:faultcodeenum' use='required' /> </xs:complexType> <xs:complexType name='faultcodeType' > <xs:sequence> <xs:element name='faultcode' type='tns:faultcodeType' minOccurs='0' /> </xs:sequence> <xs:attribute name='value' type='xsd:QName' use='required' /> </xs:complexType> </xs:schema> with an instance of; <soap:Fault xmlns:soap='http://www.w3.org/2001/09/soap-envelope' > <faultcode value='soap:Reciever' > <faultcode xmlns:app='http://example.org/apps' value='app:SomeError' /> </faultcode> </soap:Fault> Regards Gudge ----- Original Message ----- From: "Rich Salz" <rsalz@zolera.com> To: "Martin Gudgin" <marting@develop.com> Cc: "XML Protocol Discussion" <xml-dist-app@w3.org> Sent: Wednesday, November 07, 2001 12:30 PM Subject: Re: Proposal for hierarchical fault codes > > <faultcode> > > <value>soap:Reciever</value> > > <value xmlns:app='http://example.org/apps' >app:SomeError</value> > > </faultcode> > > > This doesn't imply a hierarchy to me but rather that all the fault codes are > > of equal 'importance'. But I can see the argument that the order of the > > siblings determines importance. > > Right, it's a slight shift of emphasis. > > The sender may now include multiple fault values that provide differing > levels of specificity or other description. The receiver scans through > the list looking for a QNAME it understands. > > As for schema definition, I'd actually consider tweaking it so that the > first value element must be from the standard-specificed enumerated list > of values. Subsequent optional value elements may provide more detail > for the receiver. > /r$ > > -- > Zolera Systems, Securing web services (XML, SOAP, Signatures, > Encryption) > http://www.zolera.com
Received on Wednesday, 7 November 2001 13:38:58 UTC