OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XSD design question

You might consider whether this is one of those cases where you need to move to a two layer schema. So your first level has e.g.  (Errors?, SomeData?, MoreData?) And then your second later constrains to errors or nothing.
The second layer could be implemented in xpath ( schematron or xsd assertions) or in a grammar like ( Errors | #any+)

I think some database people might say that this is nothing more than a separation of concerns: that errors must be solitary is actually a business rule. Oh yuck xml messes up the layers. (In this case that may be perhaps circular thinking: as if the limits of the expressiveness of xsd determines what a business rule is. But otherwise I think it is a fair point. When we dont layer enough we have shoehorn and finnagle our requirements into the single-level schema and get out of control complexity. )

Rick Jelliffe

On 29/05/2015 10:40 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:element name="Errors" type="ErrorsType"/>
            <xs:element name="SomeData" type="xs:string"/>
            <xs:element name="MoreData" type="xs:string"/>

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:element name="RS_Metadata" type="RS_MetadataType"/>
      <xs:element name="Errors" xsi:nil="true" type="ErrorsType"/>

  <xs:complexType name="FooRSType">
      <xs:extension base="BaseRSType">
        <xs:sequence minOccurs="0">
          <xs:element name="SomeData" type="xs:string"/>
          <xs:element name="MoreData" type="xs:string"/>

[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

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS