Masoumeh,
Thanks for your response. I will take a look at the directory you provided to see what I can learn from it. I was working on this at the end of last week and began to discover some of the problems in my plan.
Just to clarify, in my original email, when I mentioned the Geometry type, I was referring to the JTS Geometry type. So my intent was to change the method signatures for all Geo methods and replace ANode (input parameters AND return types) with JTS Geometry. In this case, all Geo methods that currently expect input as or return data as GML (ANode) would then need to be used in conjunction with the new fromXYZ() and asXYZ() methods on input and output, respectively, to parse and represent the data as needed. Are we on the same page with what I intend to do?
Problems with this approach:
1) This is an API breaking change; current users of the Geo module will need to adapt their code.
2) Don't think the module would remain strictly compliant with the EXPath Geo spec? (functions are spec'd with node() as input parameters and element() as return types with GML assumed) But the spec does talk about supporting multiple encoding types and this is one way to accomplish that goal...
I cannot think of a way to avoid these problems I listed. It would be nice if everything could remain unchanged except modify checkGeo() to somehow detect the input format and construct the JTS Geometry automatically (and efficiently!). And then for methods that return a geometry, replace gmlWriter() with something that automatically returns it in the format of the geometry(s) used on input. I don't think I would know how to implement it in this way, but if this is a better/preferred approach and you have some ideas on how to make it work, I would be glad to do it that way instead.
Question: How is the name of an XQuery Module function (e.g. geo:as-text()) reconciled with the name of the appropriate java method (Geo.asText()) when the names are not the same in this case?