W3C home > Mailing lists > Public > www-ws-desc@w3.org > August 2006

RE: XML Schema requires a type in addition to name to identify an element

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 30 Aug 2006 15:20:36 -0700
Message-ID: <37D0366A39A9044286B2783EB4C3C4E803D63989@RED-MSG-10.redmond.corp.microsoft.com>
To: <matthew.d.rawlings@jpmchase.com>, <www-ws-desc@w3.org>
Cc: <ylafon@w3.org>, "Steve Ross-Talbot" <steve@pi4tech.com>, <stabet@ruleml.org>
What precisely is the problem?  Is it that you can't constrain the
precise form of the flexible data format?  Isn't that unconstrainability
the reason to use the flexible format in the first place?  I'd like more
detail on what your type attribute would actually mean/do.  Especially
your modifications to the primer example, which appear only to add
redundant information (and therefore a possibility of error) to the
WSDL.

 

________________________________

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of matthew.d.rawlings@jpmchase.com
Sent: Sunday, August 06, 2006 9:25 AM
To: www-ws-desc@w3.org
Cc: ylafon@w3.org; Steve Ross-Talbot; stabet@ruleml.org
Subject: XML Schema requires a type in addition to name to identify an
element

 

This is implementation feedback on the Candidate Recommendation WSDL
2.0. 
  
WSDL 2.0 uses the element name to identify a message. The example from
the primer below uses the element names "ghns:checkAvailability" and
"ghns:checkAvailabilityResponse" as references to messages. 
  
<operation name="opCheckAvailability"
pattern="http://www.w3.org/2006/01/wsdl/in-out"
style="http://www.w3.org/2006/01/wsdl/style/iri" wsdlx:safe="true"> 
            <input messageLabel="In" element="ghns:checkAvailability"/> 
            <output messageLabel="Out"
element="ghns:checkAvailabilityResponse"/> 
            <outfault ref="tns:invalidDataFault" messageLabel="Out"/> 
</operation> 
  
The problem is that the name of an element is not sufficient to identify
the message type when using XML Schema. The type of the element must
also be supplied in addition to the name. This is because XML Schema
allows the type to be overridden using the xsi:type construct. 
  
In the below example the type of the element is overridden in the root
node by the use of xsi:type. 
  
<FpML version="4-2" xsi:type="DataDocument"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.fpml.org/2005/FpML-4-2
../fpml-main-4-2.xsd" xmlns="http://www.fpml.org/2005/FpML-4-2"> 
            .... 
</FpML> 
  
This is an example from the FpML schema http://www.fpml.org/
<http://www.fpml.org/> . FpML is the XML Schema standard banks, brokers,
and fund managers use to communicate within the Financial Services
industry sector. FpML is frequently extended and used internally by the
participants in the Financial Services sector, so these patterns are
widespread within this sector. 
  
FpML is an example of a schema using the Universal Root pattern
http://www.xmlpatterns.com/UniversalRootMain.shtml
<http://www.xmlpatterns.com/UniversalRootMain.shtml> . 
In the FpML schema the root element is FpML and is declared as being of
type Document. This means that the hundreds of different types of FpML
message all use the same element as their root. This makes the root
element name useless in distinguishing between messages because all
messages have the same root element. 
  
FpML is declared of type Document. 
  
<xsd:element name="FpML" type="Document"> 
            <xsd:annotation> 
                        <xsd:documentation xml:lang="en">The FpML
element forms the root for any conforming FpML instance document. The
actual structure of the document is determined by setting the 'type'
attribute to an appropriate derived subtype of the complex type
Document.</xsd:documentation> 
            </xsd:annotation> 
</xsd:element> 
  
The Document complex type is abstract. This means that as the type of
the universal root element is abstract, then all XML instance documents
must override the type using xsi:type.  Every XML document has the same
element name, and only the type changes. 
  
<xsd:complexType name="Document" abstract="true"> 
            <xsd:annotation> 
                        <xsd:documentation xml:lang="en">The abstract
base type from which all FpML compliant messages and documents must be
derived.</xsd:documentation> 
            </xsd:annotation> 
            <xsd:attributeGroup ref="StandardAttributes.atts"/> 
</xsd:complexType> 
  
I suggest the type of the element is added to the Interface definition.
This would support the usage of xsi:type in XML Schema. This would
change the primer example to the below structure. 
  
<operation name="opCheckAvailability"
pattern="http://www.w3.org/2006/01/wsdl/in-out"
style="http://www.w3.org/2006/01/wsdl/style/iri" wsdlx:safe="true"> 
            <input messageLabel="In" element="ghns:checkAvailability"
type="ghns:tcheckAvailability"/> 
            <output messageLabel="Out"
element="ghns:checkAvailabilityResponse" type="xs:double"/> 
            <outfault ref="tns:invalidDataFault" messageLabel="Out"/> 
</operation> 

This implementation feedback is the product of using WSDL 2.0 to define
services using the FpML messaging schema defined in XML Schema. The aim
is to use WSDL 2 in conjunction with XML Schema and WS-CDL within the
International Standard for Financial Services Messaging, ISO 20022
http://www.iso20022.org/. 

Matthew Rawlings
+44 791 539 7824

________________________________

 


This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
Received on Wednesday, 30 August 2006 22:40:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:41 GMT