Resolve tags without "xs" and "xsd" namespaces.

[LouizFC]

Greetings.

I have a project where I need to consume a lot of WSDL files and invoke some operations dynamically (without generating classes for it)

After I found this project, I don't need to resolve types myself anymore, so I thank you from the bottom of my heart.

The only things that I need to workaround are:

1. Frequently, the <schema> inside the WSDL comes as "simple tags", that is, instead of xsd:complexType I have only complexType. I solved this by pre-processing the xml and putting the correct tags.
2. I need to create a separate temporary file for each schema inside the WSDL, because XSDParser only accepts a filePath string.
3. Often I need to address some custom types by hand.

I wanted to know: is there are any plans to address something similar to my problem?

I took a look at the source code, and I came with some conclusions that could help me:

In XSDParserCore, move both parseMappers and xsdTypesToJava to a Defaults (or a better name) class, and allow users to pass their custom parseMappers and xsdTypesToJava to XSD Parser, if none is passed (or nulls), the default ones are used.

That would solve problem 1 and 3, but I don't know the full implications of this decision.

[lcduarte]

Hello,

You are very welcome, it is nice to know that this project seems to be helping people other than me :)

Your suggestion seems pretty straightforward and at first glance it doesn't bring any problems so I should be able to perform a new release this weekend.
Regarding your second point, there aren't really plans to solve that issue in the near future. Although it is a necessary feature since most approaches use multiple schemas it would possibly require a reasonable amount of changes in the project and at the moment I don't have the time needed to do that.

Thanks for the issue and input.

Best Regards,
Luís

[LouizFC]

I was messing with the getSchemaNode method and Inoticed that it can take a InputSource as parameter DocumentBuilderFactory.newInstance().newDocumentBuilder().parse accepts a InputSource, which can be created with a InputStream.

I haven't tested it yet, but I think that it would solve my second point, It is possible to create a InputStream from a String

[lcduarte]

Hello,

I've performed a new release, 1.0.17, which allows to pass new configurations in the XsdParser constructor. This should fix your points 1 and 3.

In regards to the InputStream, I can't recall precisely but I think I ended up not using it because I was getting some kind of problem by using it.

Regarding your second point, can you explain it further?

[LouizFC]

Thank you for the speedy release.

My second point is the following:

When parsing a WSDL, I need to strip all the "types" tag content to a different file, that's because XsdParser only accepts a filePath, which works but is kinda undesirable.

The "ideal" way for me would it be able to accept a InputStream, because we could "skip" the types on our main parser, and delegate it to XsdParser on only one read.

Maybe an API that accepts a Node would also work. We use JSoup for commodity, but everything is encapsuled, so switching to org.w3c package would not be hard too.

Edit: Also, I tested the new release just now, it works perfectly. Thank you very much

[fmcarvalho]

@LouizFC I noticed that you are not a XsdParser stargazer yet. Could you please give a star to increase popularity. Thanks