The GJXDM schema itself does NOT provide query capabilities. The two alternatives are to build queries that return GJXDM compliant ''types'' or to use web services. There is anobject model with method names to provide such query: IMHO, it is very academic in nature with minimal business analysis for practical usage; i.e., it is more of a ''controlled vocabulary'' than a real model for implementation with modern tools.
It is possible to build queries that return GJXDM compliant ''types''. One should use a naming convention for SOAP queries that follow standard camel case, using the actionTypeConstraintType convention: getPersonByID; returns Person getCourtAppearanceActorPersonByPersonName; return CourtAppearanceActorPerson (drop the dot notation), etc. Regarding the source of the input parameters, it is not possible to directly use the GJXDM naming as input parameters due to the contextual nature of the typing (complexTypes). Specifically, some of the names used in the attributes and elements are TOO GENERIC to be able to pass them as SOAP parameters. You need the entire XPATH notation to be able to define the full context / semantic definition of the parameter. Therefore, the requests are often home spun.
The second option is to use web services (WS-I conformant SOAP and WSDL) to implement the exchange. To use GJXDM in a web services context with WSDL, your schemas (subset/constraint and extension) become a source of types for the input and output parameters for each operation, as well as for faults (errors). This tends to provide a lot of flexibility in reusing these structures in the input (request) and output (reply) messages. That way, one does not need to try to figure out how to fit this all into one document schema, since the WSDL really takes on that role. The other advantage of web services and WSDL is that in most cases one can generate both requestor and service endpoint stub/skeleton code, which invokes an interface that you implement to wire up the endpoints to business logic on each end. It is also possible to choose to parse the XML, or have it de-serialized into an object graph. (This is well-supported on both the Java 2 and .NET platforms.)
The JXDM-Query-Options file in the attachment contains recommendations, best practices and lessons about query generation for the model.