.NET SDK 2.0: complex types with minOccurs = 0 and nillable = true

[HQM]

If I create an element X of a primitive type with minOccurs=0 and
nillable=true and run it through the WSDL generator I get a class with a
property "X" of the primitive type plus a boolean "XSpecified" attribute to
say if it was not specified rather than null. But if I have a complex type
with minOccurs=0 and nillable=true you don't get the "XSpecified" property.
This means you can't tell the difference between

<outer>
<x xsi:nil="true"/>
</outer>

and

<outer/>

This is a bug, I think. Now if I could only find the place in MSDN to log
bugs...FWIW I tried reporting this to a newsgroup through Visual Studio 2005
beta 2 but it would crash when it brought up the entry box. How does one
report a bug that the bug reporting system crashes?

[Zafar Abbas]

did you try the link:
http://lab.msdn.microsoft.com/productfeedback/
and click on Report a Bug.

"HQM" <HQ*@discussions.microsoft.com> wrote in message
news:F8**********************************@microsof t.com...

If I create an element X of a primitive type with minOccurs=0 and
nillable=true and run it through the WSDL generator I get a class with a
property "X" of the primitive type plus a boolean "XSpecified" attribute to say if it was not specified rather than null. But if I have a complex type
with minOccurs=0 and nillable=true you don't get the "XSpecified" property. This means you can't tell the difference between

<outer>
<x xsi:nil="true"/>
</outer>

and

<outer/>

This is a bug, I think. Now if I could only find the place in MSDN to log
bugs...FWIW I tried reporting this to a newsgroup through Visual Studio 2005 beta 2 but it would crash when it brought up the entry box. How does one
report a bug that the bug reporting system crashes?

[Zafar Abbas]

This is by design: by default we only generate xSepcified for optional
valuetypes, because from CLR point of view, null is a null. If you need to
differentiate between

<outer> <x xsi:nil="true"/> </outer>

and

<outer/>

You can add the xSpecified by hand to the generated OM, it will be honored.

"HQM" <HQ*@discussions.microsoft.com> wrote in message
news:F8**********************************@microsof t.com...

If I create an element X of a primitive type with minOccurs=0 and
nillable=true and run it through the WSDL generator I get a class with a
property "X" of the primitive type plus a boolean "XSpecified" attribute to say if it was not specified rather than null. But if I have a complex type
with minOccurs=0 and nillable=true you don't get the "XSpecified" property. This means you can't tell the difference between

<outer>
<x xsi:nil="true"/>
</outer>

and

<outer/>

This is a bug, I think. Now if I could only find the place in MSDN to log
bugs...FWIW I tried reporting this to a newsgroup through Visual Studio 2005 beta 2 but it would crash when it brought up the entry box. How does one
report a bug that the bug reporting system crashes?

[HQM]

So, if we add the xSpecified to the class x where x is an element of a
complex type B in the sequence of A then .NET will respect the Specified
semantic, even though it doesn't generate this indicator for complex types
(as opposed to "valuetypes", by which I take it you mean "primitives" like
int, etc.)? I don't follow the reasoning why this should be optional: you
seem to suggest that this is valid because if both ends are a CLR host then,
well, a null is a null. But of one end is NOT a CLR, and I NEED to
distinguish between them to send the specific message I need at the other
end, then this reasoning would be invalid. Why in a web service should the
design be predicated on the assumption that both ends are CLR? I thought
interoperability was the whole point. Am I missing something?

In any case is this treatment of xxxSpecified documented somewhere? I've
only seen the behaviour with primitives.

BTW, I tried to submit a bug, but I'm asked for profile information. I fill
in every field and hit ok or cancel and am always taken back to the profile
information form. I can't seem to get past it to file the bug report.

"Zafar Abbas" wrote:

This is by design: by default we only generate xSepcified for optional
valuetypes, because from CLR point of view, null is a null. If you need to
differentiate between

<outer> <x xsi:nil="true"/> </outer>

and

<outer/>

You can add the xSpecified by hand to the generated OM, it will be honored.

"HQM" <HQ*@discussions.microsoft.com> wrote in message
news:F8**********************************@microsof t.com...

If I create an element X of a primitive type with minOccurs=0 and
nillable=true and run it through the WSDL generator I get a class with a
property "X" of the primitive type plus a boolean "XSpecified" attribute

to

say if it was not specified rather than null. But if I have a complex type
with minOccurs=0 and nillable=true you don't get the "XSpecified"

property.

This means you can't tell the difference between

<outer>
<x xsi:nil="true"/>
</outer>

and

<outer/>

This is a bug, I think. Now if I could only find the place in MSDN to log
bugs...FWIW I tried reporting this to a newsgroup through Visual Studio

2005

beta 2 but it would crash when it brought up the entry box. How does one
report a bug that the bug reporting system crashes?

[Elena Kharitidi]

I do not see a problem with interoperability here: there is no assumption on
what type system is used by server. The schema for the "x" element allows
both forms, and .Net generated OM will be able to handle both of them
(xsi:nil=true" or omitted). The fact that your business logic depends on the
wire format is not part of the service contract, but is your application
specific.
And that custom logic could be build into the OM by adding the xSpecified
member.

"HQM" wrote:

So, if we add the xSpecified to the class x where x is an element of a
complex type B in the sequence of A then .NET will respect the Specified
semantic, even though it doesn't generate this indicator for complex types
(as opposed to "valuetypes", by which I take it you mean "primitives" like
int, etc.)? I don't follow the reasoning why this should be optional: you
seem to suggest that this is valid because if both ends are a CLR host then,
well, a null is a null. But of one end is NOT a CLR, and I NEED to
distinguish between them to send the specific message I need at the other
end, then this reasoning would be invalid. Why in a web service should the
design be predicated on the assumption that both ends are CLR? I thought
interoperability was the whole point. Am I missing something?

In any case is this treatment of xxxSpecified documented somewhere? I've
only seen the behaviour with primitives.

BTW, I tried to submit a bug, but I'm asked for profile information. I fill
in every field and hit ok or cancel and am always taken back to the profile
information form. I can't seem to get past it to file the bug report.

"Zafar Abbas" wrote:

This is by design: by default we only generate xSepcified for optional
valuetypes, because from CLR point of view, null is a null. If you need to
differentiate between

<outer> <x xsi:nil="true"/> </outer>

and

<outer/>

You can add the xSpecified by hand to the generated OM, it will be honored.

"HQM" <HQ*@discussions.microsoft.com> wrote in message
news:F8**********************************@microsof t.com...

If I create an element X of a primitive type with minOccurs=0 and
nillable=true and run it through the WSDL generator I get a class with a
property "X" of the primitive type plus a boolean "XSpecified" attribute

to

say if it was not specified rather than null. But if I have a complex type
with minOccurs=0 and nillable=true you don't get the "XSpecified"

property.

This means you can't tell the difference between

<outer>
<x xsi:nil="true"/>
</outer>

and

<outer/>

This is a bug, I think. Now if I could only find the place in MSDN to log
bugs...FWIW I tried reporting this to a newsgroup through Visual Studio

2005

beta 2 but it would crash when it brought up the entry box. How does one
report a bug that the bug reporting system crashes?

[HQM]

Hmm...the wire format -- the schema of the messages -- is EXACTLY my
contract. If my server sends <x><y xsi:nil="true"/></x> or <x/> I need to
know on the client which message was sent to understand the semantics of the
message; my server similiarly has precise and distinct meanings for the first
statement versus the second, so on the client I need a distinct way of
ensuring one message is sent instead of the other.

Peter

"Elena Kharitidi" wrote:

I do not see a problem with interoperability here: there is no assumption on
what type system is used by server. The schema for the "x" element allows
both forms, and .Net generated OM will be able to handle both of them
(xsi:nil=true" or omitted). The fact that your business logic depends on the
wire format is not part of the service contract, but is your application
specific.
And that custom logic could be build into the OM by adding the xSpecified
member.

"HQM" wrote:

So, if we add the xSpecified to the class x where x is an element of a
complex type B in the sequence of A then .NET will respect the Specified
semantic, even though it doesn't generate this indicator for complex types
(as opposed to "valuetypes", by which I take it you mean "primitives" like
int, etc.)? I don't follow the reasoning why this should be optional: you
seem to suggest that this is valid because if both ends are a CLR host then,
well, a null is a null. But of one end is NOT a CLR, and I NEED to
distinguish between them to send the specific message I need at the other
end, then this reasoning would be invalid. Why in a web service should the
design be predicated on the assumption that both ends are CLR? I thought
interoperability was the whole point. Am I missing something?

In any case is this treatment of xxxSpecified documented somewhere? I've
only seen the behaviour with primitives.

BTW, I tried to submit a bug, but I'm asked for profile information. I fill
in every field and hit ok or cancel and am always taken back to the profile
information form. I can't seem to get past it to file the bug report.

"Zafar Abbas" wrote:

This is by design: by default we only generate xSepcified for optional
valuetypes, because from CLR point of view, null is a null. If you need to
differentiate between

<outer> <x xsi:nil="true"/> </outer>

and

<outer/>

You can add the xSpecified by hand to the generated OM, it will be honored.

"HQM" <HQ*@discussions.microsoft.com> wrote in message
news:F8**********************************@microsof t.com...

> If I create an element X of a primitive type with minOccurs=0 and
> nillable=true and run it through the WSDL generator I get a class with a
> property "X" of the primitive type plus a boolean "XSpecified" attribute
to
> say if it was not specified rather than null. But if I have a complex type
> with minOccurs=0 and nillable=true you don't get the "XSpecified"
property.
> This means you can't tell the difference between
>
> <outer>
> <x xsi:nil="true"/>
> </outer>
>
> and
>
> <outer/>
>
> This is a bug, I think. Now if I could only find the place in MSDN to log
> bugs...FWIW I tried reporting this to a newsgroup through Visual Studio
2005
> beta 2 but it would crash when it brought up the entry box. How does one
> report a bug that the bug reporting system crashes?
>