Re: [xml-dev] XSD design question

You might consider whether this is one of those cases where you need to move to a two layer schema. So your first level has e.g. (Errors?, SomeData?, MoreData?) And then your second later constrains to errors or nothing.
The second layer could be implemented in xpath ( schematron or xsd assertions) or in a grammar like ( Errors | #any+)

I think some database people might say that this is nothing more than a separation of concerns: that errors must be solitary is actually a business rule. Oh yuck xml messes up the layers. (In this case that may be perhaps circular thinking: as if the limits of the expressiveness of xsd determines what a business rule is. But otherwise I think it is a fair point. When we dont layer enough we have shoehorn and finnagle our requirements into the single-level schema and get out of control complexity. )

On 29/05/2015 10:40 PM, "Hans-Juergen Rennau" <hrennau@yahoo.de> wrote:

Dear collegues,

I would appreciate to hear your opinion concerning an XSD design problem. The goal is a general pattern for modelling web service responses which are required to either deliver a normal payload or, instead, deliver error diagnostics. The problem at hand is whether or not to use a choice between an "Errors" element and a normal payload,

Until now I followed a pattern consisting of such a choice:

        <xs:choice>
          <xs:element name="Errors" type="ErrorsType"/>
          <xs:sequence>
            <xs:element name="SomeData" type="xs:string"/>
            <xs:element name="MoreData" type="xs:string"/>
          </xs:sequence>
        </xs:choice>

The advantage is the clear semantics: EITHER error OR payload. Never none or both.

Unfortunately, the choice (including the error branch) canot be shifted into a common base type, as any extension of such a base type would come after the choice, rather than extend the payload branch. Java developers complain, as the error structure is thus (from their point of view) repeated unduly.

So I wonder about the following alternative, which replaces the choice by a sequence: a nillable (or, alternatively, optional) error element is followed by the optional payload, which is provided by the response type extending the base type

<xs:complexType name="BaseRSType" abstract="true">
    <xs:sequence>
      <xs:element name="RS_Metadata" type="RS_MetadataType"/>
      <xs:element name="Errors" xsi:nil="true" type="ErrorsType"/>
    </xs:sequence>
</xs:complexType>

<xs:complexType name="FooRSType">
    <xs:complexContent>
      <xs:extension base="BaseRSType">
        <xs:sequence minOccurs="0">
          <xs:element name="SomeData" type="xs:string"/>
          <xs:element name="MoreData" type="xs:string"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
</xs:complexType>

[Note the minOccurs=0 on the sequence representing a normal payload.]

Advantage: the error structure has been shifted into a common base type of all responses. Disadvantage: the either-error-or-payload semantics is not any more captured by the schema, which would allow also an error plus a payload.

Should you have an opinion whether to prefer the choice model or the sequence model, I would like to know.

Kind regards,
Hans-Juergen Rennau