XmlProvider generates types based on name attribute in XSD schema rather than the type attribute about fsharp.data HOT 5 OPEN

hello @buvinghausen, using element names instead of types was a design decision.

Switching to a different design may not be trivial, and at the moment I have no specific advice for minimizing impacts.
But If I can find the time to think more about it, I will share my thoughts here.

from fsharp.data.

in the meantime, to mitigate the annoying problem of mapping between distinct but equivalent types, you may leverage the constructor with XElement:

let b1 = 
    DupeProvider.Branch(
        replicationId=Some "repId", 
        branchId= Some 1, 
        branchName=Some "b",
        isActive = Some true,
        location = None,
        contact = None)
let b2 = DupeProvider.Branches2(b1.XElement)

from fsharp.data.

@giacomociti quick update after applying your workaround.... first it works marvelously and at least cuts down my primary problem which was having multiple mapping functions for each cartesian product of complex type and unique names. I also fully understand your original design decision it makes perfect sense for someone to have less friction going from samples to schema. With that said I definitely would like the ability to opt into explicit schema mode that only renders back a type per complex type to cut down on all the XML element juggling. I don't see this as a pressing need any longer and so it could be planned into a future release when it makes sense. Thanks again for the assist.

from fsharp.data.

@giacomociti it seems like XsdInference.fs is your baby do you have any suggestions on a solution that will cause the least amount of impacts to the XmlProvider for existing implementations?

from fsharp.data.

@giacomociti thanks for the insight I'll give that a try and that should at least alleviate the need for all the duplicative mapping functions which would at least be a viable workaround.

from fsharp.data.