Hi Hans-Jürgen,
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
using substitution groups to specify your different response types?
Thinking out loud.
Kind regards,
Ghislain
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
_______________________________________________________________________
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
