#8 namespace setting in config file does not work

[Mads Bondo Dydensborg]

There is no code in the codebase - AFAICT - to actually load the nameSpace setting from the config file.

The attached patch fixes this for the C# case - some more code may be needed for the Java case (?). Also, there are no changes to the "Config.cs" file - it seems to be a work in progress kind of file, that is not actually used anywhere.

Also updates the docs, and fix a single typo.

[Mads Bondo Dydensborg]

Fix nameSpace config setting for C# case.

[Peter Lin]

Logged In: YES
user_id=220288
Originator: NO

I will look into enhancing the namespace configuration support. the current implementation uses the namespace if the Schema doesn't have one declared. That makes sense, since it should use the namespace in the schema. to over ride it, one option is to add a new configuration property for overriding namespace.

[Mads Bondo Dydensborg]

Logged In: YES
user_id=2768
Originator: YES

Hi Peter

I think you misunderstand my issue here: As far as I can tell, the "nameSpace" setting from the Dingo.exe.config file is _not_ actually _loaded_ any place by Dingo.

So, even though the logic is in place to handle nameSpace somewhat, in the code from SVN, the logic seems to be this:

- if the xsd contains a namespace, use that
- else use the filename of the input file (- the extension)

the patch changes this to:

- if the xsd contains a namespace, use that
- else if the config file contains a nameSpace use that
- else use the filename of the input file (- the extension)

Thinking about it, the patch may be broken, because it may assume that there _always_ is a namespace in the config file. Sorry if that is the case - I am not very used to work with that kind of config files.

Anyway: The main issue for me was, that there seems to be no code that actually loaded a nameSpace setting from the config file.

So, the patch tries to correct the behaviour of Dingo, such that it match the documentation & what you have written in forum posts. At the same time it updates the docs slightly to make this clearer.

Regards,

Mads

[Peter Lin]

Logged In: YES
user_id=220288
Originator: NO

yeah, that was a bug. It should be fixed now and should load it in Compiler.cs and JavaCompiler.cs. thanks for reporting that.

[Peter Lin]

Logged In: YES
user_id=220288
Originator: NO

I'm trying the ncip schema now. thanks for providing a link to the schema.

[Peter Lin]

Logged In: YES
user_id=220288
Originator: NO

looks like for some reason the XSD types aren't getting converted correctly. it might be the namespace declaration in the Schema. it will take a bit of time to figure out what is going on.

[Peter Lin]

Logged In: YES
user_id=220288
Originator: NO

I modified order.xsd so it uses xs:integer and dingo handles it correctly.
something about the ncip schema isn't quite right, which causes dingo to not compile xsd:integer and xsd:dateTime correctly. I'm a bit puzzled as to why that happens.

[Peter Lin]

Logged In: YES
user_id=220288
Originator: NO

I tried using .NET 1.1 XSD on the ncip schema and it works fine. i would suggest using that. I haven't figured out what is causing dingo to fail.