I see. You'd like to share the base type among different response
types. How about defining the response type with a choice, and then
Thinking out loud.
On Fri, May 29, 2015 at 3:33 PM, Hans-Juergen Rennau <
hrennau@yahoo.de> wrote:
> Hi Ghislain,
>
> this is an interesting idea, and I have not thought of that. But it seems to
> me we would then have for each operation two different response types, a
> success type and a failure type? This appears to me an increase in
> complexity perhaps not justified by the effect.
>
> Cheers,
> Hans-Jürgen
>
>
>
> Ghislain Fourny <
g@28.io> schrieb am 15:28 Freitag, 29.Mai 2015:
>
>
> 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
>
>>
>>
>>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address:
http://www.oasis-open.org/mlmanage/> Or unsubscribe:
xml-dev-unsubscribe@lists.xml.org> subscribe:
xml-dev-subscribe@lists.xml.org> List archive:
http://lists.xml.org/archives/xml-dev/> List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php>
