CODEWITHSUNDEEP
xsdwsdl
Addison
Addison

Reputation: 8347

Can extended types be used interchangeably?

Is it possible for extended types to be used interchangeably with their base element, or vice versa?

For example, I've got a WSDL, which specifies a few elements:

<s:complexType name="Original">
  <s:sequence>
    <s:element name="basic" type="s:string"/>
  </s:sequence>
</s:complexType>

<s:complexType name="Extended">
  <s:complexContent mixed="false">
    <s:extension base="tns:Original">
      <s:sequence>
        <s:element name="extra" type="s:string"/>
      </s:sequence>
    </s:extension>
  </s:complexContent>
</s:complexType>

Is it ever possible for either of these elements to be used in place of the other?

Of course, different applications/implementations will accept different things, so this question is mostly about whether or not it is correct, and follows standards.

To further extend my original example, if the WSDL specified that a message contained an Original, like so:

<s:complexType name="Other">
  <s:sequence>
    <s:element name="Original" type="tns:Original"/>
  </s:sequence>
</s:complexType>

Would it be possible to give it an Extended, while still following conventions? Or what about the other way?

What if you tried something a little hacky, such as:

<Original xsi:type="Extended">
  <basic>foo</basic>
  <extra>bar</extra>
</Original>

Thanks!

Upvotes: 0

Views: 32

Answers (1)

Sprotty
Sprotty

Reputation: 5973

What you have described is perfectly valid. In fact you have to add the 'block' attribute in order to prevent it.

So where you have a reference to 'Original' you could use xsi:type='Extended' in the XML document and use the definition defined of 'Extended'. However the converse is not true, in your example an element of type 'Extended' can not contain just an 'Original' type.

<?xml version="1.0" encoding="utf-8" ?>
<!--Created with Liquid XML 2017 Developer Bundle Edition 15.0.0.6978 (https://www.liquid-technologies.com)-->
<s:schema elementFormDefault="qualified" xmlns:s="http://www.w3.org/2001/XMLSchema">
    <s:element name="Root">
        <s:complexType>
            <s:sequence>
                <s:element name="OriginalElm" type="Original" minOccurs="0" maxOccurs="unbounded" />
                <s:element name="ExtendedElm" type="Extended" minOccurs="0" maxOccurs="unbounded" />
                <s:element name="OriginalBlocked" type="Original" block="extension" />
            </s:sequence>
        </s:complexType>
    </s:element>
    <s:complexType name="Original">
        <s:sequence>
            <s:element name="basic" type="s:string" />
        </s:sequence>
    </s:complexType>
    <s:complexType name="Extended">
        <s:complexContent mixed="false">
            <s:extension base="Original">
                <s:sequence>
                    <s:element name="extra" type="s:string" />
                </s:sequence>
            </s:extension>
        </s:complexContent>
    </s:complexType>
</s:schema>

enter image description here

The following XML is valid against the schema

<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid XML 2017 Developer Bundle Edition 15.0.0.6978 (https://www.liquid-technologies.com) -->
<Root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="D:\Development2017\Liquid\Applications\XmlStudio\Tests\UserSamples\xsiType\XSDFile3.xsd">
    <OriginalElm>
        <basic>string</basic>
    </OriginalElm>
    <OriginalElm xsi:type="Extended">
        <basic>string</basic>
        <extra>string</extra>
    </OriginalElm>
    <ExtendedElm>
        <basic>string</basic>
        <extra>string</extra>
    </ExtendedElm>
    <OriginalBlocked>
        <basic>string</basic>
    </OriginalBlocked>
</Root>

However this version of 'OriginalBlocked' is not valid as it can not be extended due to the 'block' attribute.

    <OriginalBlocked xsi:type="Extended">
        <basic>INVALID</basic>
        <extra>INVALID</extra>
    </OriginalBlocked>

A note on compatibility. Most Validating XML parsers will treat these correctly (I tested on Xerces & .Net) however most client applications will not be looking out for the xsi:type attribute. Its most likely that they will just ignore this additional data, but that's down to how they are coded.

Another small point, its a good convention to name complexTypes and simpleTypes in the form XxxxType. The parser is fine with elements attributes and types all having the same name, but it gets confusing to us!

Upvotes: 1

Related Questions