I agree with both of you about not breaking the API. I have reviewed the Geo spec more and I think I understand the intent of how to support multiple input formats.

I'm not sure about a unified XML representation, though. I would think the normal usage of WKT/WKB would be a simple type element in a document (xs:string or xs:base64Binary) or even just a literal text value.

Forgive me, thinking out loud. What if we did something like:

- Create QName of input types (make something up, how about ogc:wkt and ogc:wkb) where each contain a single text node containing the WKT/WKB data. Data in this format can be loaded directly into geo module functions because checkGeo() will be modified to recognize the QName and will parse appropriately.

- Additionally, fromText and fromBinary methods take as input a simple element (and/or literal?) and just uses the value (ignores the name). That way it will work no matter the element name in the document and not require the use of our made up type names, since it is just a simple type anyway. It can take the text value and wrap it with QName created above, which can be processed "normally." So in my example from my first email where the WKB is stored in my document as geoWKBdata, I can use fromBinary to get it loaded into the appropriate namespace without knowing or caring about what it is.
- Since EXPath Geo spec defines output of analysis functions as GML any, that should not change. But you can still use as-text and as-binary to get the WKT/WKB content anyway.

I think this would work great without breaking anything, but not sure if it is hackish. Thoughts?

Thanks,
Zach

On Wed, Oct 30, 2013 at 3:02 AM, Masoumeh Seydi Gheranghiyeh <Masoumeh.Seydi-Gheranghiyeh@uni-konstanz.de> wrote:

Hi Zachary,

I also do agree with you Christian, to not change the current API.
Based on the point which JTS contains WKT/WKB Reader/Writer functions,
adding the support of WKB/T after the format recognition seems not to be hard.
We would need a function that finds the input format, then we can call the function checkGeo
based on the input format. So, this function should be extended to read WKT/B.

About the unified XML, since geometries are based on the points, it could be possible to
form the geometries as an objects made of a set of points in this format.

> 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?

Exactly. The naming is exactly in this way.

Regards,
Masoumeh
---------------------------------------------------------------------------------------------------------------------------------------------

On Monday, October 28, 2013 18:06 CET, Zachary DeLuca <zadeluca@gmail.com> wrote:

> 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?
>
> Thanks,
> Zach