Re: Issue: SOAP Data Model Schema language may be necessary (related to #231)

Pete Hendry wrote:

>> The issue then moved to asking whether all the array member EII names 
>> have to be the same - that's currently the issue #231.
>>
> Why is it the case that these are not the same? Using schema munging 
> it is generally possible to generate a schema for soap-enc that can be 
> used in a validating parser, *except* for arrays. If the name was 
> fixed then this would resolve that problem. Currently there is no way 
> to munge a soap-enc schema into a validatable schema because of the 
> array element names being allowed to differ from the schema definition.

A schema can be made to describe a legal subset of a SOAP encoding.

This is no different with arrays that with other types.  You are 
permitted to make a schema that describes an array that has all elements 
the same.  But you may need to create arrays that have schemas where all 
elements are not the same name or type.  This is very obvious with 
non-hierarchical object graphs, to name one case.

To try and make them match perfectly (not one a subset of the other), 
even if all children of an array were required to have the same name, 
the soap specification would have to dictate what name they were all 
required to have, or a legal encoding could still just as easily violate 
your schema.

You cannot expect the SOAP and Schema to be identical in what they 
describe, so you have to take the one which is the subset as the 
authority if you want both sets of rules to be followed.

> I feel that soap implementors should not have to be concerned with 
> validating a message that can be described by the schema language when 
> a validating parser could do it instead. Most toolkits are still 
> lacking full validation simply because they cannot delegate it to a 
> parser.

Fine, if you restrict encoders to the schema-described subset, as you 
have to do anyway in a number of instances.

If you force all children of an array to have the same prescribed name, 
it prevents using tag names that are associated with proper schema 
types.  Relying on the array item type is outside of schemas and thwarts 
validation because validation is not aware of it.  Relying on xsi:type 
is something that should be optional, but this would make it mandatory. 
 Relying on xsi:type thwarts validation because it permits the sender to 
put whatever he wants into the array, and it will pass validation even 
if it is totally at odds with the array type.

Validation is safer, in my experience, using names than xsi:type, 
because the content model of the particular array can then describe 
which types are permitted.  If you hard-code the names, you throw 
eliminate possibility of being able to validate the types of the 
children of an array.  This is just fine, when you are making a specific 
schema and know the array types, but it is wrong to do it inside the 
encoding which is supposed to permit non-homogeneous arrays.

Ray Whitmer
rayw@netscape.com

Received on Tuesday, 16 July 2002 13:27:05 UTC