You can use a variation of the below via executeSqlQuery to get more control over queries:
 
 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/8.5">
   <soapenv:Header/>
   <soapenv:Body>
      <ns:executeSQLQuery sequence="1">
         <sql>select userid from enduser where UPPER(userid) like 'CUP%'</sql>
      </ns:executeSQLQuery>
   </soapenv:Body>
</soapenv:Envelope>
-----------------------------
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <ns:executeSQLQueryResponse xmlns:ns="http://www.cisco.com/AXL/API/8.5">
         <return>
            <row>
               <userid>cupuser1</userid>
            </row>
            <row>
               <userid>cupuser2</userid>
            </row>
         </return>
      </ns:executeSQLQueryResponse>
   </soapenv:Body>
</soapenv:Envelope>

 
While it is of course up to you what approach you take, I'd suggest looking twice at using SQL.  The AXL interface from what I've seen is very picky and more than a little tempermental.  I opened a thread on here about a problem I was having with an AXL call and still haven't received any response a week later, but I was able to figure out how to do what I needed using SQL.  It's not the way one *should* do the task at hand, and I view it as mildly ridiculous that the AXL interface is so quirky, but it works.  I didn't have to learn all of the internal table structures, only the small parts of the one I was interested in.