Cannot use non-namespaced (but included) types in schema about go-xml

[StabbyCutyou]

I'm running into this exact same problem.

I suspect the reason the error is not idempotent w/r/t which type isn't found, is because of how iterating maps in go is non-deterministic, and there is a lot of map iteration going on.

I think problem is here: https://github.com/droyo/go-xml/blob/master/xsd/parse.go#L148

The empty value of tns means that each time we don't find this, we set the key of "" to equal the latest schema root element we've iterated over, and so what happens is that you only get the last one under the "" key.

Then later when we go to resolve the global-list of types against the doc it thinks the namespace is for, it's only a matter of time before you hit something from one of the ones we parsed but accidentally rejected.

I've been attempting to hack around this to find a solution, and I've found something unique about each root that i can use instead of the namespace value we are trying to find, but that hasn't solved it yet, so I might still be missing something.

[StabbyCutyou]

ok, yea that solves it.

So, I don't think this is the best way to go about it, but if you alter the code in Parse, where it ranges over the schema object to do this:

		tns := root.Attr("", "targetNamespace")
		key := tns
		if key == "" {
			key = root.String()
		}

then have it set parsed[key] = s

then after pre-collecting types, the next range over schema, make a similar change:

		tns := root.Attr("", "targetNamespace")
		if tns == "" {
			tns = root.String()
		}
		s := parsed[tns]

That resolves it - assuming you don't have two documents that are completely identical. Also, this is definitely not very memory efficient but i'd wager that is less pressing than not being able to resolve types.

Unfortunately for me, I then run into this issue #117 lol

[droyo]

That's pretty clever, using the whole document as an identifier. If you want to reduce the memory usage you could use a checksum of the document as a key.

Here's what the XSD spec has to say about empty target namespaces: https://www.w3.org/TR/xmlschema-0/#UndeclaredTNS

Element declarations from a schema with no target namespace validate unqualified elements in the instance document.

@StabbyCutyou , with the fix you proposed, what does the generated code look like? Does the XML document get used as a namespace? If so, I think the xsd and xsdgen packages would have to be changed to respect empty namespaces.

What's not clear to me from the spec, is how multiple schema with an empty target namespace should be handled. Should they be merged? What do more mature tools do?

I suspect what we'll end up doing is handling undeclared target namespace specially, and updating the command line tool to allow users to select a "primary" schema file. Currently you can only select a schema by namespace, which doesn't work when they don't have namespaces.

@johnnybubonic , regarding remote schema, see #35

[johnnybubonic]

@droyo Thanks! Subscribed and will monitor there for possible fixes/merge in the future.