[seek-dev] Query deserialization does not work as designed.

[Kevin Ruland]

It was an unmodified server.

Actually the modified schema doesn't use a sequence either.  Axis has
the same bug there.

Kevin

Jing Tao wrote:

> Hi, Kevin:
>
> I need some clarification. When you sent the query to the service, the
> service is running the code base on original query schema or the
> revised query schema?
>
> I guess the service  you are talking about is the original schema(use
> choice there). If this is true, I think maybe we need to modify the
> schema: change the choice to sequence. This is the good approach I think.
>
> I will try to the test in my service too.
>
> Thanks,
>
> Jing
>
> Jing Tao
> National Center for Ecological
> Analysis and Synthesis (NCEAS)
> 735 State St. Suite 204
> Santa Barbara, CA 93101
>
> On Thu, 15 Sep 2005, Kevin Ruland wrote:
>
>> Date: Thu, 15 Sep 2005 10:20:56 -0500
>> From: Kevin Ruland <kruland at ku.edu>
>> To: seek-dev at ecoinformatics.org
>> Subject: [seek-dev] Query deserialization does not work as designed.
>>
>> Hi all,
>>
>> After looking at the query.xsd and examining the hand coded typeDesc for
>> the ANDType object, I was suspicious that the deserializer does not work
>> as inteneded.  The problem is the query.xsd specifies (correctly
>> according to standards):
>>
>>    <xs:complexType name="ANDType">
>>        <xs:annotation>
>>            <xs:documentation>A type of logical operator that requires
>> all of
>>            its child conditions to evaluate to true in order for the
>> whole
>>            clause to evaluate to true.</xs:documentation>
>>        </xs:annotation>
>>        <xs:choice maxOccurs="unbounded">
>>            <xs:element name="AND" type="ANDType"/>
>>            <xs:element name="OR" type="ORType"/>
>>            <xs:element name="condition" type="ConditionType"/>
>>        </xs:choice>
>>    </xs:complexType>
>>
>> ORType is similarly defined.
>>
>> However, Apache Axis has not been able to process xsd:choice or
>> xsd:sequence elements with maxOccurs>1.  This has been an outstanding
>> bug in Axis since the dawn of time (2003 anyway).  Even the newest
>> version of axis (1.2.1) does not process these correctly.
>>
>> The hand coded type description for AND type is identical to that
>> generated by axis when provided with the following schema:
>>
>>    <xs:complexType name="ANDType">
>>        <xs:annotation>
>>            <xs:documentation>A type of logical operator that requires
>> all of
>>            its child conditions to evaluate to true in order for the
>> whole
>>            clause to evaluate to true.</xs:documentation>
>>        </xs:annotation>
>>            <xs:element name="AND" type="ANDType" maxOccurs="unbounded"/>
>>            <xs:element name="OR" type="ORType maxOccurs="unbounded""/>
>>            <xs:element name="condition" type="ConditionType
>> maxOccurs="unbounded""/>
>>    </xs:complexType>
>>
>> Which made me think that the deserializer does not accept every message
>> which conforms to the schema.  In order to test this, I pushed messages
>> through my test digir server and printed out the QueryType objects
>> passed into it.  I envoked the query service using this query:
>>
>>   <query xmlns="ecogrid://ecoinformatics.org/ecogrid-query-1.0.0beta1"
>>          queryId="query-digir.1.1"
>> system="http://knb.ecoinformatics.org">
>>    <namespace prefix="darwin"
>> xmlns="">http://digir.net/schema/conceptual/darwin/2003/1.0</namespace>
>>    <returnfield xmlns="">/Species</returnfield>
>>    <returnfield xmlns="">/ScientificName</returnfield>
>>    <returnfield xmlns="">/Collector</returnfield>
>>    <returnfield xmlns="">/YearCollected</returnfield>
>>    <returnfield xmlns="">/InstitutionCode</returnfield>
>>    <returnfield xmlns="">/CollectionCode</returnfield>
>>    <returnfield xmlns="">/CatalogNumber</returnfield>
>>    <returnfield xmlns="">/CatalogNumberText</returnfield>
>>    <returnfield xmlns="">/DecimalLatitude</returnfield>
>>    <returnfield xmlns="">/DecimalLongitude</returnfield>
>>    <title xmlns="">mephitis macroura Query</title>
>>    <AND xmlns="">
>>     <condition concept="ScientificName" operator="LIKE"
>> xmlns="">1</condition>
>>     <OR xmlns="">
>>       <condition concept="ScientificName" operator="LIKE"
>> xmlns="">2</condition>
>>       <AND xmlns="">
>>         <condition concept="ScientificName" operator="LIKE"
>> xmlns="">3</condition>
>>       </AND>
>>       <condition concept="ScientificName" operator="LIKE"
>> xmlns="">4</condition>
>>     </OR>
>>     <AND xmlns="">
>>       <condition concept="ScientificName" operator="LIKE"
>> xmlns="">5</condition>
>>     </AND>
>>     <condition concept="ScientificName" operator="LIKE"
>> xmlns="">6</condition>
>>    </AND>
>>   </query>
>>
>> (Don't ask my why there are all the xmlns="" attributes.  I figured out
>> this was what was required by sniffing the port 8080 traffic from a
>> known good query from kepler quick search... A whole other story...)
>>
>> What the service saw was this:
>>
>> [09/15/2005 10:13:27:949 ]
>> org.ecoinformatics.ecogrid.digir.impl.DigirProxyImpl [query:454] DEBUG:
>> EcogridQueryTransformer result: <query queryId="query-digir.1.1"
>> system="http://knb.ecoinformatics.org">
>>  <namespace
>> prefix="darwin">http://digir.net/schema/conceptual/darwin/2003/1.0</namespace>
>>
>>  <returnField>/Species</returnField>
>>  <returnField>/ScientificName</returnField>
>>  <returnField>/Collector</returnField>
>>  <returnField>/YearCollected</returnField>
>>  <returnField>/InstitutionCode</returnField>
>>  <returnField>/CollectionCode</returnField>
>>  <returnField>/CatalogNumber</returnField>
>>  <returnField>/CatalogNumberText</returnField>
>>  <returnField>/DecimalLatitude</returnField>
>>  <returnField>/DecimalLongitude</returnField>
>>  <title>mephitis macroura Query</title>
>>  <AND>
>>    <AND>
>>      <condition operator="LIKE" concept="ScientificName">5</condition>
>>    </AND>
>>    <OR>
>>      <AND>
>>        <condition operator="LIKE" concept="ScientificName">3</condition>
>>      </AND>
>>      <condition operator="LIKE" concept="ScientificName">4</condition>
>>    </OR>
>>    <condition operator="LIKE" concept="ScientificName">6</condition>
>>  </AND>
>> </query>
>>
>> Notice that conditions 1 & 2 are missing.  If these clauses are removed
>> from the source message, then it satisfies the revised schema.
>>
>> What does this mean?  Even though the query.xsd is what is desired, the
>> services as implemented cannot process every message satisfying this
>> schema.  We have two options now either we adopt the modified schema and
>> use axis generated code directly, or we write custom deserializers which
>> function correctly.  Even though the revised schema is not as
>> expressive, it does still capture the same logical conditions because of
>> the associativity of AND and OR.  My preference is to accept this
>> limitation in axis and use the simplified schema.  This ends up
>> resulting in less code to maintain and we can rely on generated stubs
>> and not cram them into the repository.
>>
>> Kevin
>>
>> _______________________________________________
>> Seek-dev mailing list
>> Seek-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
>>
>>