Re: [xml-dev] XSD design question

[Ghislain Fourny <g@28.io>]

Hi Hans-Jürgen,

Have you considered using a restriction rather than an extension, to
define derived types? You could then play with occurrence indicators
in each subtype, forbidding or allowing the one or the other.

Kind regards,
Ghislain


On Fri, May 29, 2015 at 2:39 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
>
>
>