XSD Support

[giacomociti]

The XML Provider is augmented with XSD support as in FSharp.Data.Xsd.
An new parameter Schema is added. When this parameter is used (instead of Sample), an InferedType is derived from the specified XSD.

In order to leverage the existing implementation, the approach (as made evident in the unit tests) is to derive a type essentially equivalent to the one that would be inferred from a significant set of valid samples. The focus is on elements and not on complex types: provided types correspond to element shapes, not to complex types in the schema.

ToDo:

• More docs (not everything from https://fsprojects.github.io/FSharp.Data.Xsd seems to be here yet)
• Signature tests
• Green CI
• Remove GetSample

[ovatsus]

Are you going to include this on the other PR?

[giacomociti]

Actually I'm a bit confused, guess I need a "bit for dummies" crash course

[giacomociti]

I meant git for dummies

[ovatsus]

Ok, I see that this actually includes the other PR, so let's keep this as the current one, and close the other one

[ovatsus]

Avoid doing rebases because that makes things harder, just commit new commits to your baronfelxsd branch and push, and this PR will be updated

[ovatsus]

There's an xsdprovider branch that was @runefs version, I assume your implementation is an evolution of that right?

[giacomociti]

actually my implementation is more of a rewrite, there's little in common with the existing branch

[ovatsus]

What I meant is, functionality wise it's a superset, right?

[ovatsus]

I've merged with master and pushed to your branch

[ovatsus]

Maybe you can reuse the test cases from the xsdprovider branch and integrate them here as well? I merged that branch with master and pushed it so it's easy to look at

[ovatsus]

@giacomociti let me know when you're done with your changes, I'll wait for that before doing a more detailed review. I want to get this into 3.0

[giacomociti]

The last commit addresses a little issue (see fsprojects/FSharp.Data.Xsd#15).
There's one more fix I'm going to add and then only improvements for docs and test are left before you can make the review

[giacomociti]

the last commit was the last fix from FSharp.Data.Xsd fsprojects/FSharp.Data.Xsd#19
I hope that perf impact of using InferdType as cache key is negligible

[ovatsus]

Yes, perf impact should be negligible, but do make sure to add some tests for those elements with the same name (both signature test, and a test that gets the value at runtime)

[giacomociti]

@ovatsus I think we have enough tests now, so you may start the code review (unless you want me to also fix the GetSample issue, but it is not trivial and may take a while). In the meantime I can finish the docs, although I'm having troubles with generate.fsx

[ovatsus]

What error are you getting with generate.fsx?

[giacomociti]

I got this on Ubuntu:

/home/giacomo/Documenti/Repos/FSharp.Data/docs/tools/generate.fsx(25,1): error FS0078: Unable to find the file 'Fsharp.Charting.dll' in any of
/usr/lib/mono/4.5
/usr/lib/mono/4.5/Facades
/home/giacomo/Documenti/Repos/FSharp.Data/docs/tools/../../packages/test/FSharp.Charting/lib/net45
/home/giacomo/Documenti/Repos/FSharp.Data/docs/tools
/usr/lib/mono/fsharp/

but on Windows it worked.
Let me know if the docs are ok

[ovatsus]

Oh, I don't think FSharp.Charting works on linux, so that should be fine

[ovatsus]

I'll have a look at removing the GetSample method. The way it was done in CsvProvider doesn't work for you as you're passing the schema as the sample to get the common code to download it

[giacomociti]

I've found a way to avoid generating GetSamples by factoring out a couple of functions in the common helper code. Maybe you can figure out a better way

[ovatsus]

Since something similar will be needed eventually for JsonSchema, I refactored a bit the generateType folder to support schemas better, still need to finish a couple of more things, will probably push that tomorrow

[giacomociti]

I added a couple of tests: the first one cover nillable elements, which are supported albeit they may seem strange.
The second test is on the generated ctors; for all the simple types supported (except xs:date), we check to produce valid xml (as long as the arguments passed are valid because of course the type system cannot enforce certain xsd constraints like for example regex patterns).
We exclude xs:date because of this issue: the xml gets formatted with the time component, hence it is valid as xs:dateTime but invalid as xs:date.
An option would be to remove xs:date from the (already limited) set of simple types supported, falling back to string. On the other hand this would break the nice property of deriving the same InferedType that get infered, without a schema, from valid samples.

[ovatsus]

This is now released as part of 3.0.0-beta4. Sorry for taking so long

[giacomociti]

Great! Thanks @ovatsus