[0.1.4] Generated types incomplete with no errors or warnings

[Zsar]

Tested with the profile definition of Cisco AnyConnect Secure Mobility Client Version 4.10.03104.

Steps to reproduce:

1. ~/go/bin/gocomply_xsd2go convert AnyConnectProfile.xsd xsd . generates ./ns1/models.go
2. (e.g.) struct ClientInitialization is empty

Expected: struct ClientInitialization should contain all defined child elements, e.g. UseStartBeforeLogon.

More generally, expected result is either of:

• no errors or warnings are emitted, all output files are valid and complete
• errors are emitted to stderr, number and state of output files do not matter
• warnings are emitted to stderr, affected output files should be valid, unaffected output files should also be complete

N.b.: It seems that the second argument to gocomply_xsd2go has neither effect nor documentation. Initially I had github.com/gocomply/scap in there as per README.md . I changed it to xsd to see what would happen.

[isimluk]

Patches welcome!

[Zsar]

Generation now seems to be element-complete but the tags do not look quite right.
The particular example file also generates two name collisions CertificatePinListPin and HostEntry. Collision detection seems to have renamed them alright, they simply still collide thereafter due to questionable (if valid) design of the XSD itself.

I'll investigate both and update this issue, create a new issue for the name collision.

... As for the latter: Would it seem acceptable/desirable to you to split the generated files into more than one package? That seems to me the most straightforward way to solve these collisions (go packages are "equivalent to" namespaces and in a language with namespaces I'd create per type one namespace to put all contained types into => unique path to each type supports all XSD-valid name collisions). Added bonus would be that the type names themselves do not get mangled (as they do by the current collision detection). If not, what would you yourself consider a(n ideal) solution?

[isimluk]

The particular example file also generates two name collisions CertificatePinListPin and HostEntry. Collision detection seems to have renamed them alright, they simply still collide thereafter due to questionable (if valid) design of the XSD itself.

I have noticed the name collision. It seems that the mechanism that avoids name collisions will need to be a bit more clever. I have some initial design, but haven't had a chance to finish it out. I was only able to move the name collision logic to a single place so the code handling it can be more cohesive.

... As for the latter: Would it seem acceptable/desirable to you to split the generated files into more than one package? That seems to me the most straightforward way to solve these collisions (go packages are "equivalent to" namespaces and in a language with namespaces I'd create per type one namespace to put all contained types into => unique path to each type supports all XSD-valid name collisions). Added bonus would be that the type names themselves do not get mangled (as they do by the current collision detection). If not, what would you yourself consider a(n ideal) solution?

So, currently we create separate module per namespace. Good example is available here: https://github.com/GoComply/scap/tree/master/pkg/scap/models <- this is all generated by gocomply/xsd2go. One go module per namespace.

I think dividing modules further would not yield better results in better cases.

If not, what would you yourself consider a(n ideal) solution?

I don't see fundamental issue in the current approach. It seems that name collision detection just needs to be an inch better.

[Zsar]

Mmh. Unsure. I mean, yes, it could just loop until no collisions are left - but the colliding names in the example are quite obnoxiously long even after the first replacement. I do not think this solution - while technically perfectly sufficient - would yield readable code.