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)
