Fix namespace resolution when elementFormDefault is 'unqualified' or unset on xs:schema

[benweint]

This change fixes the way that XML namespaces are determined for non-top-level elements & attributes within an XSD schema, resulting in more correct generated code in cases where the schema element lacks the elementFormDe257, fault / attributeFormDefault attributes, or has them set to the default value of unqualified.

There are multiple open issues (at least #257, #243, and #232) that I think all trace back to this area of the code and would be helped (if not entirely solved) by this change.

Background

An XSD schema may contain multiple element and attribute definitions. These definitions may be either top-level (direct children of the <schema> element itself) or local (more deeply nested, for example under a <complexType> element).

In the case of top-level element and attribute definitions, the XML namespace assigned to the element or attribute is always equal to the value of the targetNamespace attribute of the containing <schema> element.

In the case of local element or attribute definitions, their XML namespaces are determined via a more complex set of rules described in § 3.2.2.2 Mapping Rules for Local Attribute Declarations (attributes) and § 3.3.2.3 Mapping Rules for Local Element Declarations (elements) of the XSD spec. In short: whether local elements & attributes 'inherit' the targetNamespace of the containing <schema> is determined by their targetNamespace and form attributes or (in the absence of both), the elementFormDefault / attributeFormDefault attributes on the containing schema.

gowsdl is currently applying the rule for top-level element and attribute definitions to all elements and attributes, regardless of whether they are top-level or not, resulting in incorrect namespaces in xml tags, and thus broken code-generation for some schemas containing local element / attribute definitions.

Test coverage

There was actually test coverage of these cases, but the existing test assertions were incorrect.

In particular, the stored expected output for the EPCIS test introduced in #166 encoded a number of incorrect element namespaces. I double-checked the example XML payloads in the standard here to confirm that the existing test was incorrect. See the examples section 9.6 in the EPCIS standard for an example demonstrating that the <EPCISBody> element, for example, is un-namespaced.

[bayasdev]

+1