...
I
...
was
...
wondering
...
if
...
someone
...
could
...
help
...
better
...
document
...
the
...
WSDL
...
for
...
the
...
API
...
interfaces.
...
There
...
are
...
two
...
different
...
versions
...
that
...
are
...
generated.
...
One
...
is
...
at:
...
http://host/fedora/wsdl?api=API-A
...
and
...
another
...
is
...
at:
...
http://sandbox.ischool.drexel.edu:8080/fedora/services/access?wsdl. 
...
;
...
These
...
two
...
WSDL
...
documents
...
are
...
different
...
as
...
well.
...
Specifically
...
with
...
the
...
findObjects()
...
definition.
...
When
...
consuming
...
this
...
service,
...
the
...
axis
...
interpretation
...
gives
...
you
...
conditions
...
and
...
terms
...
on
...
the
...
search
...
request
...
object,
...
while
...
the
...
fedora
...
WSDL
...
gives
...
you
...
just
...
item.
...
For
...
example,
...
when
...
consuming
...
in
...
.NET
...
the
...
code
...
differences
...
are:
...
AXIS
...
WSDL
FieldSearchQuery fsq = new FieldSearchQuery();
Condition c = new Condition();
c.@operator = ComparisonOperator.has;
c.property = "subject";
c.value = "*";
fsq.conditions = new Condition[] { c };
string[] sr = { "pid", "title", "subject" };
FieldSearchResult fsr = a.findObjects(sr, "50", fsq);
Fedora WSDL
fsq.Item= new Condition[] { c };
Either way, the service call fails when using conditions, and only succeeds when using a string-based terms query. The servlet returns "org.xml.sax.SAXException:
...
Found
...
character
...
data
...
inside
...
an
...
array
...
element
...
while
...
deserializing"
...
when
...
using
...
the
...
axis
...
API-A
...
and
...
throws
...
a
...
preliminary
...
"type
...
not
...
allowed"
...
exception
...
when
...
using
...
the
...
fedora
...
WSDL.
...
Does
...
anyone
...
have
...
a
...
workaround
...
for
...
this,
...
or
...
a
...
better
...
way
...
of
...
consuming
...
the
...
service
...
that
...
isn't
...
documented?
...