Use JTSKit/json-table-schema-py instead of typecast

[pwalsh]

Use JTSKit/json-table-schema-py instead of typecast

[pudo]

I guess it's your call since this lib exists on the okfn org, but I do intend to support as much of the JTS spec in typecast as appears reasonable. But if JTS is a rolling spec where the scope is defined by okfn's vendor libraries, you obviously win....

To be honest, the exact purpose and development path of jtskit have really confused me, which is why I didn't want to base any software on it. It seems to me to be a mix of JTS reference functions and half an implementation of messytables. I've also found that it doesn't work under Python 2, crashing with ASCII errors upon infer.

[rufuspollock]

@pudo can you open an issue for any bugs you have found with jtskit (or have you done so already)? They should definitely get fixed.

[pudo]

Yep, frictionlessdata/tableschema-py#19

[pwalsh]

@pudo I know you have a penchant for rolling your own, but, why not help us get JTSKit in better shape rather than starting a new one?

I don't see the relationship to messytables - IMHO messytables is a real kitchen sink library that does lots of different things, and this is one of the reasons why a standalone json table schema lib exists - explicitly not to be tied to the rest of messytables.

[pudo]

Some clarification: I need typecast for jsonmapping, which does not use JTS (instead JSON Schema), and I'm hoping that it will be adopted by messytables so that the lib becomes less of a kitchen sink.

I really think that type casting is a piece of functionality that makes sense as a package, since it requires a good bit of complexity to get right (the code in typecast, which comes from messytables, has matured for four years now and there's still plenty to do).

There are other steps that should be taken to make messytables better, but let's discuss those in the other issue tracker. Still, given that messytables is a mature library which is adopted across OKFN's and other products, I would propose we don't give up on it easily and instead make it rock in the context of the JTS suite of tools!

[pwalsh]

Sure, as you suggested here, we can probably depend on typecast for parts of the JTS typecasting in JTSKit. But, because we'll always be following the JTS spec, and particularly the interplay between type + format there, then there remains a clear and strong usecase for "JTS-specific typecasting", in a way that probably should not be in messytables anyway, as far as I see. For the moment, what is called "JTS" in messytables barely reflects the current JTS spec.

[pwalsh]

Also @pudo if you have issues with the JTSKit API, please do open issues for them: bugs and design issues alike. Thanks.

[rufuspollock]

@pwalsh + @pudo one possibility is that messytables "v2" fully supports JTS. In that case messytables v2 would be "JTS infer" and we could depend on that.

Also for this current library (jts-sql) I think we could assume that typecasting has happened - we have the JTS already (?). In that case all we need is to use JTS + CSV to load into SQL. The question of how the JTS is generated can come from any of several JTS inference libraries (and we can work out asap which one to focus on). PS: I think i will try and create a diagram showing the various library parts and post in https://discuss.okfn.org/c/open-knowledge-labs/data-packages

[pudo]

+1 on messytables v2

[rufuspollock]

OK, here's the diagram and post: https://discuss.okfn.org/t/data-package-libraries-overview/957 - next thing to add is a list of the various implementations and how they fit together.

[pwalsh]

Closing in favour of #7

Also see #3 (comment)