[seek-dev] Query deserialization does not work as designed.
Jing Tao
tao at nceas.ucsb.edu
Thu Sep 15 09:48:36 PDT 2005
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
>
>
More information about the Seek-dev
mailing list