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

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!