XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
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

Hi!

If you schema(s) are being used Web Services I would stay away from substitution groups in schemas. The NIEM schemas heavily use substitution groups and on a project using NIEM schemas we found that most web services software (at least all the ones our trading partners were using) didn't support substitution groups. The software handled substitution groups differently. BizTalk and JBoss were two pieces of software that had issues. There were more but I can't remember which ones they were. I wrote an XSLT that converted the substitution groups into choices and all the software that was being used by exchange partners worked.

If you do use substitution groups I would make sure that you test the schema with all known web services software that will be used in your environment. If the software is unknown I would be cautious and avoid substitution groups. We found this issue late in development and it caused some major headaches.

Betty

On 2015-05-29 09:40, Ghislain Fourny wrote:
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)



[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