Re: XSD design question

From: Hans-Juergen Rennau <hrennau@yahoo.de>
To: Rick Jelliffe <rjelliffe@allette.com.au>
Date: Sat, 30 May 2015 12:14:04 +0000 (UTC)

Play the video

Let me try to grasp the main idea. "Layer 1" would describe normal payloads and refrain from combining them with error diagnostics into a choice. This would be left to "layer 2". So layer 1 would contain components like "FooResponsePayload" and "BarResponsePayload", whereas layer 2 would contain elements (and types) "FooResponse(Type)" and "BarResponse(Type)". Layer 2 would be in fact derived - implied by layer 1 (XyzResponse = (errors|XyzResponsePayload). But as you mention XPath, which would be unnecessary, I probably have not yet completely understood, what is lacking? At present, at least, I see two issues.

Issue#1: As the payload does not necessarily have a single root element (in contrast to the message), some of the payloads would have to be xs:group, rather than type components. But groups cannot extend other groups, and I think a general pattern not supporting inheritance is no option. (Neither would be a pattern constraining payloads to have a single root.)

Issue#2: The pattern would not solve the original problem - how to shift error diagnostics into a common "response base type".

Just to avoid misunderstandings, concerning layering, separation of concerns etc., let me emphasize one point: what I need is an XSD design pattern associating every service message with a single XSD type definition and a single XSD element declaration. Whatever the approach, this must be the result.

Kind regards,

Hans-Jürgen

Rick Jelliffe <rjelliffe@allette.com.au> schrieb am 11:18 Samstag, 30.Mai 2015:

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: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

References:
- Re: XSD design question
  - From: Rick Jelliffe <rjelliffe@allette.com.au>

[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!

Download The World's Best XML IDE!

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

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.

XML Editor - Download a 15 Day Free Trial Now >

See What's New in Stylus Studio >

Buy Stylus Studio - XML Editor - Now >