Schema with top-level elements about go-xml HOT 16 CLOSED

@flisky , PR #36 should resolve your issue.

To more clearly define the fix criteria for this issue, it can be considered resolved when a WSDL that references the top-level elements in a schema can be processed, even when the element names don't match their type names. For example,

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="example.com">
  <types>
    <schema xmlns="http://www.w3.org/2001/XMLSchema">
      <element name="myParam1" type="myType1"/>
      <complexType name="myType1">
        <element name="field1" type="int" />
      </complexType>
    </schema>
  </types>
  <message name="myMessage">
    <part name="parameters" element="myParam1" />
  </message>
</definitions>

I'm considering one of the following approaches:

• Add an Elements and Attributes member to xsd.Schema for top-level elements.
• Add a complexType tns:_Self to the xsd.Schema.Types map that has all the top-level elements and attributes.

from go-xml.

I added a mediocre test in #62 . I'm calling this issue resolved.

I made #63 to fix another problem I saw running wsdlgen on the WSDL linked above, and I've opened #61 to address (hopefully) the final problem with the generated code there.

from go-xml.

EDIT: it seems I'm talking another relative problem -- "the parent element's name doesn't pass to complexType, thus complexType goes anonymous".

Any updates on this?

The UseFieldNames options doesn't work for anonymous complexType, and at that time, the element information is already lost.

I use the following dirty hack to handle this problem, just for anyone in need -

diff --git a/xsd/parse.go b/xsd/parse.go
index 7af2c0c..7755c3d 100644
--- a/xsd/parse.go
+++ b/xsd/parse.go
@@ -384,6 +384,20 @@ func (s *Schema) addElementTypeAliases(root *xmltree.Element, types map[xml.Name
                                return fmt.Errorf("could not lookup type %s for element %s",
                                        el.Prefix(ref), el.Prefix(name))
                        } else {
+                               switch base := t.(type) {
+                               case *SimpleType:
+                                       if !base.Anonymous {
+                                               break
+                                       }
+                                       base.Name = name
+                                       base.Anonymous = false
+                               case *ComplexType:
+                                       if !base.Anonymous {
+                                               break
+                                       }
+                                       base.Name = name
+                                       base.Anonymous = false
+                               }
                                s.Types[name] = t
                        }
                }

from go-xml.

The unpackTopElements function in xsd/parse.go was supposed to do this, but it has a bug:

	child.SetAttr("", "name", el.Attr("", "name"))

should be followed by

	el.Children[i] = child

that would cover types contained by top-level elements, and remaining anonymous types within elements should be covered by the UseFieldNames options (since, as far as I know, the only other valid place for an element is within a ).

from go-xml.

There's a few more issues with the unpackTopElements function:

• unpackTopElements is a bad name; it's not "unpacking" anything, just copying the name.

• it descends the subtree under an element when it should only be looking at direct children. Consider this xsd:

    <element name="temperature">
      <simpleType>
        <union>
          <simpleType>
            <restriction base="string"><pattern value="-?[0-9]F" /></restriction>
          </simpleType>
          <simpleType>
            <restriction base="string"><pattern value="-?[0-9]C" /></restriction>
          </simpleType>
        </union>
      </simpleType>
    </element>
  

There's only 1 direct child type, but unpackTopElements would simply give up.

from go-xml.

@droyo is this in progress? If not I may jump in. We have an immediate need for a fix.

After a quick look through the code base, I think I prefer the tns:_Self approach as it seems to be a far smaller change.

from go-xml.

@ianlopshire I have not been working on this one, any help would be appreciated!

from go-xml.

OK, PR #54 should have helped. I'll need to confirm if this is fully resolved.

from go-xml.

@droyo This seems to have fixed the mapping issues for me, but has broken something with the xsd type white listing. Not types are included in the wsdlgen output. Everything seems to work as expected if I disable the whitelisting and just include all types.

from go-xml.

@ianlopshire could you link the wsdl you're using? I'd like to make a test to prevent future regressions.

from go-xml.

It was probaly this change. Previously it would mistakenly add "" to the list of target name spaces.

So I'm thinking you have a wsdl with a schema that doesn't have a target namespace, or the use of "" in the namespaces whitelist causes more types to be pulled in. I know there are a few problems for schema without a target namespace, and haven't come up with a good(correct) way to handle those, since the XSD spec has special rules(surprise!) for the "default" target namespace.

from go-xml.

This is the WSDL I'm trying to use. It does have a target name space on the schema.

When generating, only the functions come through and no structs. I'm pretty sure it is a whitelist issue because commenting out cfg.registerXSDTypes(def) on wsdlgen.go#L116 fixes the issue.

from go-xml.

Thanks for the WSDL, I'm able to reproduce the issue. I'll try to dig into it further over the next few days.

from go-xml.

Ok, issue is that I changed the wsdl and wsdlgen packages to treat element and type attributes of a part separately, but at wsdlgen.go#L373 I still use the Type field indiscriminately.

The fix is to lookup the type for the provided element, as is already done during the code generation phase.

from go-xml.

PR #57 helps, but is kind of ugly, and there are still a few issues:

• 24HourWorkday is not a valid identifier -- I had to add a replacement rule for that
• It doesn't pull in the Communication_Usage_TypeEnumeration type. I don't know why :)

from go-xml.

I tried for awhile to get the xsdgen package to do the right thing, but I gave up and chose your workaround instead. PR #58 removes the whitelist from wsdlgen.

I've opened #59 to fix the xsdgen package's whitelist feature. This issue should be resolved, but I'll keep it open until I can get a test written.

from go-xml.