By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,562 Members | 1,242 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,562 IT Pros & Developers. It's quick & easy.

wsdl.exe -when elementFormDefault="qualified" elements have null n

P: n/a
Using .NET framework 1.1 SP1, .NET framework SDK 1.1 SP1, Visual Studio .NET
2003, hotfixes 892202 and 823639.

I create a proxy class using wsdl.exe, and in the serialized XML request, I
see that any elements that are nested elements in the schema (not global
elements) have their namespaces set to the null namespace. I can see that
the proxy classes have serialization attributes specifying these nested
elements as unqualified:
/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute(Form= System.Xml.Schema.XmlSchemaForm.Unqualified)]
public AuthenticationDataLoginData LoginData;

and so in the XML, the namespace is set to null:

<AuthenticationData>
<LoginData xmlns="">
etc...

I expected that this was happening because in the schema file,
elementFormDefault="unqualified". Therefore, I would expect that if I
changed it to elementFormDefault="qualified", I would see the proxy class
change and would get rid of the xmlns="" in the LoginData field. That didn't
happen - the generated proxy is exactly the same. In other words, no matter
what you set for elementFormDefault, wsdl.exe behaves as if the
elementFormDefault is "unqualified", and the namespace is set to null.
Is this a known bug in wsdl.exe - is there a fix available? I'd like to
minimize the changes to the schema if I can, and I have an external
requirement that no manual changes to the generated proxy class be needed.

Thanks,

--
Cindy
May 13 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Hi
First of all i would like to know what RunTime Version are you using.
I am using version 1.1.4322.573 and its working perfectly fine. The schema
file is generated with elementformdefault="Qualified" value. Yes but you are
right. This is problem and this has been discussed many times on many groups.
I dont have KB number of this bug but what seems to me that this issue gets
resolved if you replace unqualified with qualified value. As solution i will
suggest that you use earlier version of WSDL to generate Stub. As I have seen
similar problem in VS 2005 too.

"CindyRob" wrote:
Using .NET framework 1.1 SP1, .NET framework SDK 1.1 SP1, Visual Studio .NET
2003, hotfixes 892202 and 823639.

I create a proxy class using wsdl.exe, and in the serialized XML request, I
see that any elements that are nested elements in the schema (not global
elements) have their namespaces set to the null namespace. I can see that
the proxy classes have serialization attributes specifying these nested
elements as unqualified:
/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute(Form= System.Xml.Schema.XmlSchemaForm.Unqualified)]
public AuthenticationDataLoginData LoginData;

and so in the XML, the namespace is set to null:

<AuthenticationData>
<LoginData xmlns="">
etc...

I expected that this was happening because in the schema file,
elementFormDefault="unqualified". Therefore, I would expect that if I
changed it to elementFormDefault="qualified", I would see the proxy class
change and would get rid of the xmlns="" in the LoginData field. That didn't
happen - the generated proxy is exactly the same. In other words, no matter
what you set for elementFormDefault, wsdl.exe behaves as if the
elementFormDefault is "unqualified", and the namespace is set to null.
Is this a known bug in wsdl.exe - is there a fix available? I'd like to
minimize the changes to the schema if I can, and I have an external
requirement that no manual changes to the generated proxy class be needed.

Thanks,

--
Cindy

May 14 '06 #2

P: n/a
Though this problem is not coming on my side but i tried to regenerate this
case, the version i m using creates WSDL with the qualified value of
elementformdefault, instead if i tried to remove defaultnamespace of my
webservice, it compiled with this messege

This web service is using http://tempuri.org/ as its default namespace.
Recommendation: Change the default namespace before the XML Web service is
made public.

So, I tempered the generated WSDL and changed value of elementformdefault
from qualified to unqualified, and I came up with the same proxy code as u
posted here. So it means that you need to change this value to Qualified and
use some earlier version Or use autogenerated proxy using .net IDE.

"Altaf Al-Amin Najwani" wrote:
Hi
First of all i would like to know what RunTime Version are you using.
I am using version 1.1.4322.573 and its working perfectly fine. The schema
file is generated with elementformdefault="Qualified" value. Yes but you are
right. This is problem and this has been discussed many times on many groups.
I dont have KB number of this bug but what seems to me that this issue gets
resolved if you replace unqualified with qualified value. As solution i will
suggest that you use earlier version of WSDL to generate Stub. As I have seen
similar problem in VS 2005 too.

"CindyRob" wrote:
Using .NET framework 1.1 SP1, .NET framework SDK 1.1 SP1, Visual Studio .NET
2003, hotfixes 892202 and 823639.

I create a proxy class using wsdl.exe, and in the serialized XML request, I
see that any elements that are nested elements in the schema (not global
elements) have their namespaces set to the null namespace. I can see that
the proxy classes have serialization attributes specifying these nested
elements as unqualified:
/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute(Form= System.Xml.Schema.XmlSchemaForm.Unqualified)]
public AuthenticationDataLoginData LoginData;

and so in the XML, the namespace is set to null:

<AuthenticationData>
<LoginData xmlns="">
etc...

I expected that this was happening because in the schema file,
elementFormDefault="unqualified". Therefore, I would expect that if I
changed it to elementFormDefault="qualified", I would see the proxy class
change and would get rid of the xmlns="" in the LoginData field. That didn't
happen - the generated proxy is exactly the same. In other words, no matter
what you set for elementFormDefault, wsdl.exe behaves as if the
elementFormDefault is "unqualified", and the namespace is set to null.
Is this a known bug in wsdl.exe - is there a fix available? I'd like to
minimize the changes to the schema if I can, and I have an external
requirement that no manual changes to the generated proxy class be needed.

Thanks,

--
Cindy

May 14 '06 #3

P: n/a
Altaf,

Thank you for your response. My runtime version is 1.1.4322.2032. I cannot
go back to 523 as you suggest because of some other wsdl.exe bugs - you may
have noticed the hotfixes I pointed out as having installed. Our wsdl
includes 2 schemas, schema 1 and schema 2, and schema1 and schema2 both
include schema3. The elementFormDefault setting I am referring to is set in
schema1 and schema2 which are imported by the wsdl. Going back to the
runtime you suggest (which I have experimented with) causes a problem because
of the bug 892202 with including external schemas.

Yes, manually changing the proxy class to Qualified instead of unqualified
does work around the problem, but our customer does not want to have to
manually change their proxies. We are generating schemas based on their
datatype, and generating a version of our wsdl which is specific to their
datatype on the fly. However, just a change from unqualified to Qualified
doesn't seem to arduous to me, we'll see if they agree.

Thank you for your response
--
Cindy
"Altaf Al-Amin Najwani" wrote:
Though this problem is not coming on my side but i tried to regenerate this
case, the version i m using creates WSDL with the qualified value of
elementformdefault, instead if i tried to remove defaultnamespace of my
webservice, it compiled with this messege

This web service is using http://tempuri.org/ as its default namespace.
Recommendation: Change the default namespace before the XML Web service is
made public.

So, I tempered the generated WSDL and changed value of elementformdefault
from qualified to unqualified, and I came up with the same proxy code as u
posted here. So it means that you need to change this value to Qualified and
use some earlier version Or use autogenerated proxy using .net IDE.

"Altaf Al-Amin Najwani" wrote:
Hi
First of all i would like to know what RunTime Version are you using.
I am using version 1.1.4322.573 and its working perfectly fine. The schema
file is generated with elementformdefault="Qualified" value. Yes but you are
right. This is problem and this has been discussed many times on many groups.
I dont have KB number of this bug but what seems to me that this issue gets
resolved if you replace unqualified with qualified value. As solution i will
suggest that you use earlier version of WSDL to generate Stub. As I have seen
similar problem in VS 2005 too.

"CindyRob" wrote:
Using .NET framework 1.1 SP1, .NET framework SDK 1.1 SP1, Visual Studio .NET
2003, hotfixes 892202 and 823639.

I create a proxy class using wsdl.exe, and in the serialized XML request, I
see that any elements that are nested elements in the schema (not global
elements) have their namespaces set to the null namespace. I can see that
the proxy classes have serialization attributes specifying these nested
elements as unqualified:
/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute(Form= System.Xml.Schema.XmlSchemaForm.Unqualified)]
public AuthenticationDataLoginData LoginData;

and so in the XML, the namespace is set to null:

<AuthenticationData>
<LoginData xmlns="">
etc...

I expected that this was happening because in the schema file,
elementFormDefault="unqualified". Therefore, I would expect that if I
changed it to elementFormDefault="qualified", I would see the proxy class
change and would get rid of the xmlns="" in the LoginData field. That didn't
happen - the generated proxy is exactly the same. In other words, no matter
what you set for elementFormDefault, wsdl.exe behaves as if the
elementFormDefault is "unqualified", and the namespace is set to null.
Is this a known bug in wsdl.exe - is there a fix available? I'd like to
minimize the changes to the schema if I can, and I have an external
requirement that no manual changes to the generated proxy class be needed.

Thanks,

--
Cindy

May 15 '06 #4

P: n/a
IF you could try to find out the KB number of the bug you are referring to
that would be very helpful. Thanks
--
Cindy
"Altaf Al-Amin Najwani" wrote:
Hi
First of all i would like to know what RunTime Version are you using.
I am using version 1.1.4322.573 and its working perfectly fine. The schema
file is generated with elementformdefault="Qualified" value. Yes but you are
right. This is problem and this has been discussed many times on many groups.
I dont have KB number of this bug but what seems to me that this issue gets
resolved if you replace unqualified with qualified value. As solution i will
suggest that you use earlier version of WSDL to generate Stub. As I have seen
similar problem in VS 2005 too.

"CindyRob" wrote:
Using .NET framework 1.1 SP1, .NET framework SDK 1.1 SP1, Visual Studio .NET
2003, hotfixes 892202 and 823639.

I create a proxy class using wsdl.exe, and in the serialized XML request, I
see that any elements that are nested elements in the schema (not global
elements) have their namespaces set to the null namespace. I can see that
the proxy classes have serialization attributes specifying these nested
elements as unqualified:
/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute(Form= System.Xml.Schema.XmlSchemaForm.Unqualified)]
public AuthenticationDataLoginData LoginData;

and so in the XML, the namespace is set to null:

<AuthenticationData>
<LoginData xmlns="">
etc...

I expected that this was happening because in the schema file,
elementFormDefault="unqualified". Therefore, I would expect that if I
changed it to elementFormDefault="qualified", I would see the proxy class
change and would get rid of the xmlns="" in the LoginData field. That didn't
happen - the generated proxy is exactly the same. In other words, no matter
what you set for elementFormDefault, wsdl.exe behaves as if the
elementFormDefault is "unqualified", and the namespace is set to null.
Is this a known bug in wsdl.exe - is there a fix available? I'd like to
minimize the changes to the schema if I can, and I have an external
requirement that no manual changes to the generated proxy class be needed.

Thanks,

--
Cindy

May 15 '06 #5

P: n/a
As an update, when I changed the wsdl include of the external schema to
specify elementFormDefault="qualified" explicitly, the problem went away.

I didn't realize it was necessary to re-define the elementFormDefault at
include time - I had thought it would pick it up from the definition in the
schema file. But, changing the include statement in the wsdl:types section
from this:

<xsd:schema
targetNamespace="http://www.ibm.com/xmlns/db2/cm/beans/1.0/schema">
<xsd:include schemaLocation="myschema.xsd"/>
</xsd:schema>

to this:

<xsd:schema elementFormDefault="qualified"
targetNamespace="http://www.ibm.com/xmlns/db2/cm/beans/1.0/schema">
<xsd:include schemaLocation="myschema.xsd"/>
</xsd:schema>

got rid of the problem. I had been changing the value of elementFormDefault
in the declaration of myschema.xsd, thinking that it would be picked up by
the include, not realizing that the implicit value for elementFormDefault in
the wsdl, which is of course unqualified by default, would override the
setting in the schema.
--
Cindy
"CindyRob" wrote:
IF you could try to find out the KB number of the bug you are referring to
that would be very helpful. Thanks
--
Cindy
"Altaf Al-Amin Najwani" wrote:
Hi
First of all i would like to know what RunTime Version are you using.
I am using version 1.1.4322.573 and its working perfectly fine. The schema
file is generated with elementformdefault="Qualified" value. Yes but you are
right. This is problem and this has been discussed many times on many groups.
I dont have KB number of this bug but what seems to me that this issue gets
resolved if you replace unqualified with qualified value. As solution i will
suggest that you use earlier version of WSDL to generate Stub. As I have seen
similar problem in VS 2005 too.

"CindyRob" wrote:
Using .NET framework 1.1 SP1, .NET framework SDK 1.1 SP1, Visual Studio .NET
2003, hotfixes 892202 and 823639.

I create a proxy class using wsdl.exe, and in the serialized XML request, I
see that any elements that are nested elements in the schema (not global
elements) have their namespaces set to the null namespace. I can see that
the proxy classes have serialization attributes specifying these nested
elements as unqualified:
/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute(Form= System.Xml.Schema.XmlSchemaForm.Unqualified)]
public AuthenticationDataLoginData LoginData;

and so in the XML, the namespace is set to null:

<AuthenticationData>
<LoginData xmlns="">
etc...

I expected that this was happening because in the schema file,
elementFormDefault="unqualified". Therefore, I would expect that if I
changed it to elementFormDefault="qualified", I would see the proxy class
change and would get rid of the xmlns="" in the LoginData field. That didn't
happen - the generated proxy is exactly the same. In other words, no matter
what you set for elementFormDefault, wsdl.exe behaves as if the
elementFormDefault is "unqualified", and the namespace is set to null.
Is this a known bug in wsdl.exe - is there a fix available? I'd like to
minimize the changes to the schema if I can, and I have an external
requirement that no manual changes to the generated proxy class be needed.

Thanks,

--
Cindy

May 15 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.