Re: [xml-dev] XSD design question

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