XmlProvider generates types based on name attribute in XSD schema rather than the type attribute

[buvinghausen]

The side effect of this is I have a separate type for every instance of a type that appears with a different name within the XSD. This becomes a giant pain when writing mapping code because now I have to repeat the mapping functions N number of times where N is the number of unique names that a type appears within the XSD when the underlying structure is identical across them.

I fully realize fixing this will be a breaking change and thus require a 7.x release if fixed but the more complicated the XSD gets the worse this problem spirals out of control...

I've included a real world XSD which demonstrates the core issue and have organized the duplicate types into groups to illustrate the underlying issue as it exists today

Repro Repo

[buvinghausen]

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

[giacomociti]

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.

[giacomociti]

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)

[buvinghausen]

@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.

[buvinghausen]

@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.