[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSD design question

• From: Betty Harvey <harvey@eccnet.com>
• To: XML Development <xml-dev@lists.xml.org>
• Date: Fri, 29 May 2015 10:18:24 -0400

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

--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Betty Harvey                         | Phone:  410-787-9200  FAX: 9830
Electronic Commerce Connection, Inc. |
harvey@eccnet.com                    | Washington,DC XML Users Grp
URL:  http://www.eccnet.com          | http://www.eccnet.com/xmlug
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
Member of XML Guild (www.xmlguild.org)

• Follow-Ups:
  • Re: XSD design question
    • From: Hans-Juergen Rennau <hrennau@yahoo.de>

• References:
  • Re: XSD design question
    • From: Ghislain Fourny <g@28.io>
  • Re: XSD design question
    • From: Hans-Juergen Rennau <hrennau@yahoo.de>
  • Re: XSD design question
    • From: Ghislain Fourny <g@28.io>