Use Import / Included schemas for code Generation

[markfarnan]

Currently it appears the XSDGEN tool does not reference and included/imported schema files.

There is an 'Import' function in the Parser code, but unclear how to use it.

Is there any documentation on how to Code-Gen an XSD Schema that uses extensive external imports ?
My use case is an open standard domain specific XML Schema, which has an extensive data model and uses about 20 different included files (With nested includes/imports).

I can share the entire schema if required as it is public.

[droyo]

The current handling of imports is a bit of a hack. The xsdgen tool requires that you provide paths to all required files on the command line, including files imported by an XSD, and imports of imports and so on. #35 is open to have a utility to retrieve those files recursively.

So as far as I can tell, you should be able to generate code for your schema, you will just have to go through the extremely tedious process of acquiring and referencing all of the relevant XSD files. If that is feasible, you can try that and let me know if it doesn't work. If it does work we can mark this issue as a duplicate of #35.

[kortschak]

I have a case where all the files necessary are available in a single directory. Handing xsdgen the paths to all of the xsd files fails to result in a successful codegen; doing schema surgery and manually inlining the includes in the root does give a successful result.

$ xsdgen -v *.xsd
complexType parent: could not find type id-type in namespace http://www.gexf.net/1.2draft for attribute for

Am I missing something here? or is this not expected to work?

[droyo]

This is expected to work. Looking at your example I see "id-type" defined in gexf.xsd, under targetNamespace "http://www.gexf.net/1.2draft", defined here. It's then used in data.xsd.

I believe what is happening is that the same targetNamespace is split across multiple files. The way xsd.Parse works, it expects for a targetNamespace to be fully defined within a single file. In short, I'm not properly handling the <include> statement: https://www.w3.org/TR/xmlschema-1/#compound-schema

There is a step during the xsd parsing process, resolvePartialTypes, that looks up types like id-type. I think the way forward is to pull this step out of the per-document parsing, and defer it to the very end, after all documents have been parsed.

[aaronmmanzano]

I believe I've handled the splitting of namespaces across files in my PR. I'm sure it needs work, and you may prefer it be handled in another manner else where within the logic, but it may be a start.

[davidalpert]

this is an older issue but I ran into the same problem. I took a crack at resolving it on a local branch by:

• added an -f flag to the xsdgen CLI app to toggle on following schemas;
• updated the read file logic so that when the follow schema flag is set it will call xsd.Imports(..) on each file as it's read, recursively reading in those files (and their imports) so that all the imported schema files are all in memory;
• added a MergeTypes() method to the xsd.Schema type to merge types so long as the target namespaces are equivalent;
• updated the parse logic to merge schema types by target namespace rather than overwrite them, allowing all the imported types from a given target namespace to collect into a single xsd.Schema object;

this seems to work, as it satisfies the assumptions of the resolvePartialTypes method, that all type resolution can happen within a single xsd.Schema object.

if this approach seems reasonable I am happy to offer these changes as a pull request for consideration.

[davidalpert]

I didn't find the PR that @aaronmmanzano mentioned until this morning, I assume that https://github.com/droyo/go-xml/pull/72 is it? I'm going to have a look through to catch up on what I missed in the conversation and see how I can help.

[davidalpert]

PR #72 has some merge conflicts with master in parse.go which are complex enough that I don't want to get it wrong.

In the meantime, here are a pair of PRs, separated as I think they serve different purposes, for consideration:

• #131 optionally follow imports in xsd files
• #132 teach xsd.Schema how to merge type maps

[droyo]

I merged #131 but I am doing some research and apparently it is valid to have import cycles. Or, at least, it is not explicitly invalid. I have not worked with a wide range of XSD files; does anyone have an idea how common circular imports are? #131 will have an infinite loop on such input.

[nikolawannabe]

I also ran into this issue when generating code for Onix 3.0.

For me, I had to manually merge the 3 files for the generation to succeed.

[dalcorta]

I suggest using fixtrading.org XSD since it is very complex. I downloaded it from https://www.fixtrading.org/standards/fixml/ fixmlschema_FIX.Latest_EP286.zip