[FX XSD] cg_setarray_type validity ?

Hello,

It seems that there is a mistake in the definition of an CG array parameter, taken from the COLLADA 1.4.1 XSD :


	<xs:complexType name="cg_setarray_type">
		<xs:choice minOccurs="0" maxOccurs="unbounded">
			<xs:group ref="cg_param_type"/>
			<xs:element name="array" type="cg_setarray_type"/>
			<xs:element name="usertype" type="cg_setuser_type"/>
		</xs:choice>
		<xs:attribute name="length" type="xs:positiveInteger" use="optional"/>
	</xs:complexType>

In the current definition, a CG array may contain multiple elements of different type (choice repeated N times), but I guess an array should not have such a behavior.

Thus, this definition should be more appropriate :


	<xs:complexType name="cg_setarray_type">
		<xs:choice>
			<xs:group ref="cg_param_type" maxOccurs="unbounded"/>
			<xs:element name="array" type="cg_setarray_type"  maxOccurs="unbounded"/>
			<xs:element name="usertype" type="cg_setuser_type"   maxOccurs="unbounded"/>
		</xs:choice>
use="optional"/>
	</xs:complexType>

A set the minOccurs to 1, because I think that we can’t get the array type if it contains no element.

Moreover, I wonder what is the role of the length attribute, as the number of elements given in the array declaration should give the number of elements in the CG array. Could you confirm or infirm ?

Thanks in advance.

Tom

Can you report this to http://www.khronos.org/bugzilla please?

Thanks.

This solution still allows you to fill in combinations of the cg_param_type <float>,<int>,etc which are not valid. So making this changes does not a tangable solution where you don’t have to check each element of the array for consistancy. It is an improvement but not a very significant one.

-Daniel

Yes, you’re right dhoro, I gracefuly mismatched myself.

Moreover, my new solution enables an array to contain arrays of different types, so the problem seems to be even more complicated.

Is there a way in XSD to say “repeat a choice of a group N times” ? I’m not sure, because referencing a group is seen as if you put the ‘choice’ at the place of the reference to the group.

I guess one solution would be to create one array type for each param type (and also for arrays type, in order to make multi-dim arrays), but it would be quite painful.

We can also create a group named cg_paramarray_type, which would be a choice containing a sequence of each types, as following :


<xs:group name="cg_paramarray_type">
  <xs:choice>
    <xs:element name="bool" type="cg_bool" maxOccurs="unbounded"/>
    <xs:element name="bool1" type="cg_bool1" maxOccurs="unbounded"/>
    ....
  </xs:choice>
</xs:group>

Instead of referencing the cg_param_type group (with maxOccurs=“unbounded”) in the cg_setarray_type definition, we wouls reference the cg_paramarray_type. This seems to solve the simple-typed array homogeneity issue, but not the multi-dim array issue.

Does anyone see another solution ?

Perhaps you can use the <xs:list> type to create aggregate types in combination with the previous example?

The goal is to allow N-dimensional homogenous arrays (right?), so a recursive schema definition of scalar and aggregate types seems like the right approach.