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

When we last discussed CR078, there was not much interest in adding a mechanism for describing the allowed (required?) values of the xsi:type attribute, as was proposed by the commenter.  Instead, I took an action for a few weeks to try to enumerate some ways you could still use WSDL to describe an FpML service, characterized by a single root element which wraps a variety of other formats.

1)       Use element="#any".  This reduces the descriptiveness completely, which is at odds with the desire to describe a specific FpML structure.
2)       Use element="fmpl:FpML".  This allows only FpML documents, but doesn't further constrain the precise structure of FpML.  This isn't unreasonable, as it doesn't circumvent the kind of flexibility for which the schema was originally designed, yet it doesn't support the use case of specifying a subset of the possible structures that is intended for the operation.
3)       Wrap the FpML types in a set of wrapper elements (unfortunately not named FpML), so the content of the element can be precisely determined.  Unfortunately this morphs the root element name on the wire, so the messages conform to the wrapped schema, but not directly to the unwrapped FpML schema.
4)       Use an extension of your own invention to specify further validation constraints (such as the allowed values of xsi:type).  This is slightly more machine-readable than specifying the further constraints in text.

That's about all the reasonable options I could come up with.  Any others?

________________________________
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of Jonathan Marsh
Sent: Thursday, August 31, 2006 11:29 AM
To: matthew@stickledown.com; www-ws-desc@w3.org
Subject: 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!