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

FYI, I've added this to the issues list as CR078
[http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR078].

 

________________________________

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Matthew Rawlings
Sent: Thursday, August 31, 2006 11:04 AM
To: www-ws-desc@w3.org
Subject: 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!