- From: Matthew Rawlings <matthew@stickledown.com>
- Date: Thu, 31 Aug 2006 19:03:44 +0100
- To: <www-ws-desc@w3.org>
- Message-Id: <200608311803.k7VI3hJf020570@pyramid-04.kattare.com>
I confirm that you now understand this correctly. I agree with you that the existing industry standard XML Schema schemata are poorly adapted to being used in a WSDL service. This is to be expected as XML Schema predated WSDL. I disagree that "one was stuck using a flexible schema (for political reasons)". My personal opinion is the reason is that current industry standard XML Schema schemata have long histories and large installed bases of standards-compliant schema. The choice is whether to adapt WSDL to XML Schema or adapt existing XML Schema schemata to WSDL. Both are possible, one is more costly than the other. My personal opinion is it would be far better if people could be convinced for good engineering reasons. My personal opinion is that on an engineering basis the type of the element is more important than its name when dealing with a type system such as XML Schema provides. My personal opinion is a clear statement (positive or negative), from the W3C WSDL Working Group on the merits of using xsi:type in the root element would help industry standards groups prepare to adopt WSDL 2.0. Please make a statement to guide designers of XML Schema schemata in their adoption of WSDL. Matthew Rawlings _____ From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of Jonathan Marsh Sent: 31 August 2006 17:17 To: matthew.d.rawlings@jpmchase.com; 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 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!
Received on Thursday, 31 August 2006 18:03:59 UTC