Peter Ciuffetti wrote:
> I noticed that the WSDL2Java operation did not pick up on the fact
> that an echoedRequest element in a searchRetrieveResponse can contain
> an optional searchRetrieveRequest and/or a series of
> unknownParameter's. The class it generated only contains setter's and
> getter's for 'unknownParameter'.
Sorry, the above was a red herring. WSDL2Java created an EchoRequest
class that extended SearchRetrieveRespnse, so all the methods available
in that class were accessible through EchoRequest.
...However, there were two other minor aspects of xcql.xsd that
WSDL2Java did not handle correctly:
Two parameters, prefixesType and modifiersType, are defined in the xsd
as repeating sequences of a single element:
<xs:complexType name="prefixesType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="prefix" type="prefixType"/>
</xs:sequence>
</xs:complexType>
and
<xs:complexType name="modifiersType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="modifier" type="modifierType"/>
</xs:sequence>
</xs:complexType>
For these, WSDL2Java did not create array getters and setters to access
the repeating children, it only created:
private gov.loc.www.zing.cql.v1_0.xcql.PrefixType prefix;
public gov.loc.www.zing.cql.v1_0.xcql.PrefixType getPrefix()
and
private gov.loc.www.zing.cql.v1_0.xcql.ModifierType modifier;
public gov.loc.www.zing.cql.v1_0.xcql.ModifierType getModifier()
If I changed the xql.xsd to define these types as '[1] sequence of [1 or
more] repeating elements' as opposed to '[1 or more] sequences of [1]
element', e.g.
<xs:complexType name="prefixesType">
<xs:sequence>
<xs:element name="prefix" type="prefixType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
and
<xs:complexType name="modifiersType">
<xs:sequence>
<xs:element name="modifier" type="modifierType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
...then WSDL2Java generated a more functional class that modelled the
prefixes and modifiers as arrays, with array getter's and setter's:
private gov.loc.www.zing.cql.v1_0.xcql.PrefixType[] prefix;
public gov.loc.www.zing.cql.v1_0.xcql.PrefixType[] getPrefix()
public void setPrefix(gov.loc.www.zing.cql.v1_0.xcql.PrefixType[] prefix)
public gov.loc.www.zing.cql.v1_0.xcql.PrefixType getPrefix(int i)
public void setPrefix(int i, gov.loc.www.zing.cql.v1_0.xcql.PrefixType
value)
and
private gov.loc.www.zing.cql.v1_0.xcql.ModifierType[] modifier;
public gov.loc.www.zing.cql.v1_0.xcql.ModifierType[] getModifier()
public void setModifier(gov.loc.www.zing.cql.v1_0.xcql.ModifierType[]
modifier)
public gov.loc.www.zing.cql.v1_0.xcql.ModifierType getModifier(int i)
public void setModifier(int i,
gov.loc.www.zing.cql.v1_0.xcql.ModifierType value)
So this change may be desireable for future versions of the xcql schema.
I don't think it changes the semantics as far as validation goes, but it
makes WSDL2Java happier.
Regards,
Pete Ciuffetti
KnowledgeSite, Inc.
|