- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Thu, 31 Aug 2006 09:16:42 -0700
- To: <matthew.d.rawlings@jpmchase.com>, <www-ws-desc@w3.org>
- Cc: <stabet@ruleml.org>, "Steve Ross-Talbot" <steve@pi4tech.com>, <ylafon@w3.org>
- Message-ID: <37D0366A39A9044286B2783EB4C3C4E803D63E31@RED-MSG-10.redmond.corp.microsoft.com>
Thanks for the complete example, I understand the scenario as far as the schema goes, but I'm not sure what you want added to WSDL to support this use case. One way to interpret your proposal is that wsdl:input/@type constrains the allowed values of the xsi:type attribute appearing in the message instance. In other words, the message must match both the element name defined by wsdl:input/@element, and have an xsi:type attribute with the value given by wsdl:input/@type (and structure corresponding to it). The schema you provide allows the transport element to take on a variety of structures within the same element name. In my experience this is so the client (or generator) of the data has flexibility. The receiver is informed of the client's structural choice using xsi:type. In WSDL, the schema defines the schema types deemed acceptable by the service. If a WSDL specified a flexible schema such as the one below, one would expect it to be delegating the choice of structure to the client. Yet in your scenario, this delegated flexibility then is constrained. The WSDL defines a flexible schema, and then takes this flexibility away by only allowing a specific xsi:type value. One would presumably only need this capability because one was stuck using a flexible schema (for political reasons) that was poorly adapted to a WSDL-described service, which isn't a very compelling scenario. If you really need and expect flexible structures, I would generally expect the WSDL to simply declare element=#any. Please feel free to correct any misconceptions above, especially if I've misinterpreted your proposal in some way. I'm just trying to understand better so we can resolve this quickly! ________________________________ From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of matthew.d.rawlings@jpmchase.com Sent: Thursday, August 31, 2006 1:51 AM To: www-ws-desc@w3.org Cc: stabet@ruleml.org; Steve Ross-Talbot; ylafon@w3.org Subject: RE: XML Schema requires a type in addition to name to identify an element Jonathan - In answer to your assertion: Close study of XML Schema shows that the proposal does not add redundant information. xsi:type allows the type of an element to be changed in the XML instance document independently of what the XML Schema states the type of the element is. In answer to your question: The precise problem "is that the name of an element is not sufficient to identify the message type when using XML Schema". The purpose of the WSDL message is to identify the type of the message. It is not always possible to identify the type of the message from the root element name, because the type may be overridden by an xsi:type declaration. Example XML Schema schema with an a universal abstract root node of "transport": <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="transport" type="Vehicle" abstract="false"/> <xs:complexType name="Vehicle" abstract="true"/> <xs:complexType name="Bicycle"> <xs:complexContent> <xs:extension base="Vehicle"> <xs:sequence> <xs:element name="wheel" minOccurs="2" maxOccurs="2"/> <xs:element name="colour"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="Car"> <xs:complexContent> <xs:extension base="Vehicle"> <xs:sequence> <xs:element name="wheel" minOccurs="4" maxOccurs="4"/> <xs:element name="fuel"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="Aeroplane"> <xs:complexContent> <xs:extension base="Vehicle"> <xs:sequence> <xs:element name="wings"/> <xs:element name="configuration"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="Horse"> <xs:complexContent> <xs:extension base="Vehicle"> <xs:sequence> <xs:element name="colour"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema> First example XML instance "Tiger Moth" showing the use of xsi:type: <?xml version="1.0" encoding="UTF-8"?> <transport xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Vehicles.xsd" xsi:type="Aeroplane"> <wings>4</wings> <configuration>differential aileron control setup</configuration> </transport> Second example XML instance "Trigger" showing the use of xsi:type: <?xml version="1.0" encoding="UTF-8"?> <transport xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Vehicles.xsd" xsi:type="Horse"> <colour>Palomino</colour> </transport> The importance of the example is that both Tiger Moth and Trigger have the same root element but different types. Tiger Moth has a root element of "transport" which has a type of "Aeroplane", whereas Trigger has a root element of "transport" but a type of "Horse". The universal root element pattern is common in schema used for messaging. Until the type of the element can be identified then WSDL 2.0 will not work with the existing industry standard schema that use xsi:type. Matthew Rawlings +44 791 539 7824 "Jonathan Marsh" <jmarsh@microsoft.com> 30/08/2006 23:20 To: <matthew.d.rawlings@jpmchase.com>, <www-ws-desc@w3.org> cc: <ylafon@w3.org>, "Steve Ross-Talbot" <steve@pi4tech.com>, <stabet@ruleml.org> Subject: RE: XML Schema requires a type in addition to name to identify an element 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.
Received on Thursday, 31 August 2006 16:17:23 UTC