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

Re: XSD design question

  • From: Ghislain Fourny <g@28.io>
  • To: Hans-Juergen Rennau <hrennau@yahoo.de>
  • Date: Fri, 29 May 2015 15:40:36 +0200

Re:  XSD design question
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
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.