PreferOptionals param for XmlProvider

[lasandell]

I've come across a couple situations where I've wanted to treat all primitive values in the XML document as strings rather than relying on type inference to figure this out. I was thinking about about adding some settings to the type provider for this; I already have some of them working locally. They would be as follows:

• ForceStrings - Infer all primitive values as strings, regardless of content.
• UseEmptyStrings - If a string is not always present, use an empty string to represent its absence rather than inferring the string option type for the value.

Additionally, I'd like it to infer empty elements as strings, similar to what it currently does with attributes. Right now, it infers an empty class type for an empty element. I don't know if this should be another option (TreatEmptyElementAsString?) or if it should just be the standard behavior.

If we decide these should be added, I can also try to include similar behavior in the JSON and CSV providers. However, those are a little different since they have unquoted values; so should the ForceStrings setting apply to all values or just quoted ones? I'm thinking the former. Or we could have an enumeration, e.g. type ForceString = Always | Never | WhenQuoted.

Please let me know your thoughts on these potential features. I think it is useful to have more control over the projection; however, I wouldn't want to add a bunch of stuff in that nobody else would use.

[ovatsus]

The ForceStrings is already being added in #658

About UseEmptyStrings, CsvProvider does that by default, and you can use PreferOptionals to change it, but on XmlProvider and JsonProvider that's the default and there is no param to change it. It's mostly for back compat reasons, as I did a small poll some time ago and almost everyone prefered optionals by default. In which situation would you prefer an empty string instead?

About the TreatEmptyElementAsString, the reason for the current behaviour, is that then you can do .Xml and get to the actual element when it's populated at runtime, with a string you would loose that ability

[lasandell]

Sorry for the late response. Good to see that the NoTypeInference option has been added.

As for the use case, this is when I only care about mapping between two different document structures but don't care about the types of the individuals values. That way I don't have to deal with the option or XElement. Maybe I could add the PreferOptionals flag to the XmlProvider but default it to true?

[lasandell]

Hmm... the InferTypesFromValues flag on the XmlProvider seems to not do anything.

> type X = XmlProvider<"<A>1</A>", InferTypesFromValues = false>;;
type X = XmlProvider<...>
> X.GetSample();;
val it : int = 1

I would have expected to receive a string since I set the flag to false.

[ovatsus]

Oh, the check that was made here: https://github.com/fsharp/FSharp.Data/blob/d8e6f1b3cd3059d625e768370d575cd5dd133da1/src/Xml/XmlInference.fs#L27 is missing here: https://github.com/fsharp/FSharp.Data/blob/d8e6f1b3cd3059d625e768370d575cd5dd133da1/src/Xml/XmlInference.fs#L35, so it's only working correctly for attributes, not values.
Can you please send a pull request with the fix?

[lasandell]

Will do. To avoid confusion, I'll probably create a separate PR just for that fix.

[ovatsus]

Is there anything else missing or can I close this issue?

[lasandell]

Please leave it open. My PR only fixed the InferTypesFromValues setting. I'd also like to try implementing at least the PreferOptionals setting for the XmlProvider.

[ovatsus]

Ok

[ovatsus]

Hi Luke, are you planning on submitting a PR for the PreferOptionals?

[lasandell]

Probably eventually. It's been at the back of my mind, I've just been focused on other things so haven't gotten around to it yet. :-)