Passing a Dataset to a webservice

[Arne]

How do I pass a dataset to a webservices? I need to submit a shoppingcart
from a pocket PC to a webservice.
What is the right datatype?
II have tried dataset as a datatype, but I can't get it to compile.
<WebMethod()> _
Public Function VerifySku(ByVal skus As XmlDataDocument ) As DataSet

Test program :
Dim cartSet As DataSet
cartSet = ws.VerifySku(ca rtSet)

Error:
C:\Projects\Sho ppingCartWeb\Sh oppingCartTest\ Test.vb(37): Value of type
'System.Data.Da taSet' cannot be converted to '1-dimensional array of
System.Object'.

[Drew Marsh]

Scott M. wrote:

This approach works for passing the DataSet schema as well. We can
the DataSet's GetXML and we can use the DataSet's GetXMLSchema to
send and then we can use the DataSet's ReadXMLSchema as well as
ReadXML to re-populate.

What's the point in having a schema if all you can declare is that you're passing me a loosely typed xsd:string??? How does that help anyone figure out what data structure they're supposed to send to you when all they're looking at is your WSDL? The DataSet itself doesn't really care about the XML schema at all. It's perfectly happy with whatever well-formed XML it might generate, so this isn't about helping the DataSet, it's about helping the developer that looks at the signature of your method.

This approach just seems to miss the entire point of XML, XML Schema and strongly typed message signatures altogether. Think of it this way, if we're talking 100% managed code and you take a parameter of type DataSet... how do I know what structure that DataSet is supposed to contain? Or maybe the better question is: Would you type all your .NET methods to take/return string? I'm guessing you wouldn't, so why should your web methods be any different?

Cheers,
Drew

_______________ _______________ _____
Drew Marsh
Chief Software Architect
Mimeo, Inc. - http://www.mimeo.com
Weblog - http://blog.hackedbrain.com/

[Scott M.]

"Drew Marsh" <dr****@hotmail .no.spamming.co m> wrote in message
news:u5******** ******@tk2msftn gp13.phx.gbl...

Scott M. wrote:

This approach works for passing the DataSet schema as well. We can
the DataSet's GetXML and we can use the DataSet's GetXMLSchema to
send and then we can use the DataSet's ReadXMLSchema as well as
ReadXML to re-populate.
What's the point in having a schema if all you can declare is that you're
passing me a loosely typed xsd:string??? How does that help anyone figure
out what data structure they're supposed to send to you when all they're
looking at is your WSDL? The DataSet itself doesn't really care about the
XML schema at all. It's perfectly happy with whatever well-formed XML it
might generate, so this isn't about helping the DataSet, it's about
helping the developer that looks at the signature of your method.

You are mistaken or don't understand what I'm saying. If we START with a
strongly typed DataSet, we can extract its data AND its schema (data types
and all) using DataSet.GetXML and DataSet.GetXMLS chema. These 2 string
values could then be sent anywhere we want (presumably over the wire to
another layer) and used to re-construct a new DataSet. This results in a
DataSet that knows what data types we are dealing with as well as the rest
of the structure of the data.

This approach just seems to miss the entire point of XML, XML Schema and
strongly typed message signatures altogether. Think of it this way, if
we're talking 100% managed code and you take a parameter of type
DataSet... how do I know what structure that DataSet is supposed to
contain? Or maybe the better question is: Would you type all your .NET
methods to take/return string? I'm guessing you wouldn't, so why should
your web methods be any different?
See above. I fully understand XML and its implications. I have done what I
am proposing above (which is not difficult at all) and it works very nicely
(preserving data-types and structure across layers).

Cheers,
Drew

_______________ _______________ _____
Drew Marsh
Chief Software Architect
Mimeo, Inc. - http://www.mimeo.com
Weblog - http://blog.hackedbrain.com/

[Drew Marsh]

Scott M. wrote:

You are mistaken or don't understand what I'm saying. If we START
with a strongly typed DataSet, we can extract its data AND its schema
(data types and all) using DataSet.GetXML and DataSet.GetXMLS chema.
These 2 string values could then be sent anywhere we want (presumably
over the wire to another layer) and used to re-construct a new
DataSet. This results in a DataSet that knows what data types we are
dealing with as well as the rest of the structure of the data.
Actually I understand you 100%. Here... your answer to the following question should put an end to the debate:

Q: Do you indicate the schema of your parameter in your WSDL?
See above. I fully understand XML and its implications. I have done
what I am proposing above (which is not difficult at all) and it
works very nicely (preserving data-types and structure across
layers).

This depends on your answer above. I going to go out on a limb and guess your answer is "no". Why? Well because you already told me you pass the schema with the data. In that case you have failed to describe the data structure to the caller and are simply passing strings around. Remember, the client to your web method might not be using DataSets. Your client doesn't know anything about a schema being passed inline with the data and may not have the ability to interpret that schema into a structure that is meaningful to them at runtime. You've completely ruled out the ability for any agnostic proxy generation tool to help the developer communicate with your class in a strongly typed way.

At least if your parameter was DataSet instead of string you'd be one step closer to leveraging the power of XML. However, assuming you haven't hand tuned the schema yourself, .NET does not know what the DataSet might contain, so it generates the following schema for you in the WSDL:

<s:element minOccurs="0" maxOccurs="1" name="myDataSet Param">
<s:complexTyp e>
<s:sequence>
<s:element ref="s:schema" />
<s:any />
</s:sequence>
</s:complexType>
</s:element>

Literally that says: "I expect someone to pass me an XML Schema document followed by any well-formed XML document.". That's great, at least it's closer, but not many other toolkits have something like a DataSet that actually knows how to interpret that data into anything meaningful for the client programmer to code against. In the end neither approach here is leveraging the power of strongly typed messaging and leave much to be desired from the consumer's perspective.

Cheers,
Drew

[Scott M.]

> Actually I understand you 100%. Here... your answer to the following

question should put an end to the debate:

Q: Do you indicate the schema of your parameter in your WSDL?
I am not talking about passing these pieces of XML from a web service client
to a web service. I am talking about a process that takes place fully on
the back end. There is no WSDL involved here. This is why I said that you
probably were misunderstandin g me. What I am proposing would be something
that a webmethod would be calling deeper in the n-tier of the server that is
running the web service. You don't use WSDL to get these layers
communicating since they are both part of the same assembly. You are under
the impression I've been describing a web service to web service client,
which I have not.

See above. I fully understand XML and its implications. I have done
what I am proposing above (which is not difficult at all) and it
works very nicely (preserving data-types and structure across
layers).
This depends on your answer above. I going to go out on a limb and guess
your answer is "no". Why? Well because you already told me you pass the
schema with the data. In that case you have failed to describe the data
structure to the caller and are simply passing strings around. Remember,
the client to your web method might not be using DataSets.

Allthough, I believe we've found the source of your confusion, the OP did
say that DataSets were what he/she intended to use so your point is mute.
Your client doesn't know anything about a schema being passed inline with
the data and may not have the ability to interpret that schema into a
structure that is meaningful to them at runtime. You've completely ruled
out the ability for any agnostic proxy generation tool to help the
developer communicate with your class in a strongly typed way.
See above.

At least if your parameter was DataSet instead of string you'd be one step
closer to leveraging the power of XML. However, assuming you haven't hand
tuned the schema yourself, .NET does not know what the DataSet might
contain, so it generates the following schema for you in the WSDL:

<s:element minOccurs="0" maxOccurs="1" name="myDataSet Param">
<s:complexTyp e>
<s:sequence>
<s:element ref="s:schema" />
<s:any />
</s:sequence>
</s:complexType>
</s:element>

Literally that says: "I expect someone to pass me an XML Schema document
followed by any well-formed XML document.". That's great, at least it's
closer, but not many other toolkits have something like a DataSet that
actually knows how to interpret that data into anything meaningful for the
client programmer to code against. In the end neither approach here is
leveraging the power of strongly typed messaging and leave much to be
desired from the consumer's perspective.
Again Drew, we are talking about situations where DataSets WILL be used.

Cheers,
Drew

[Drew Marsh]

Scott M. wrote:

I am not talking about passing these pieces of XML from a web service
client to a web service. I am talking about a process that takes
place fully on the back end. There is no WSDL involved here. This
is why I said that you probably were misunderstandin g me.
Well, yeah, that sure might explain it. After all this is the microsoft.publi c.dotnet.framew ork.**webservic es** newsgroup. :)
What I am
proposing would be something that a webmethod would be calling deeper
in the n-tier of the server that is running the web service. You
don't use WSDL to get these layers communicating since they are both
part of the same assembly. You are under the impression I've been
describing a web service to web service client, which I have not.
So wait... let us pause to discuss this design for a second:

<digression level="moderate ">
If this is a deeper layer, why aren't you passing strong types (at least DataSets) around at that point? Are you actually telling us that you're passing strings of XML from a web method written in managed code to a data layer also written in managed code and doing the parsing within that layer? Forget losing strong typing at the web service layer, you seem to have given that up at a lower level already.

The web service should be the one to convert the XML to strongly typed data, or at the very least DataSet, before passing it on to the next layer? I mean, that's usually the whole point of a Web Service/Method: to act as a façade over a set of lower level systems. It's entire reason for existence is to bridge the communication gap. If you're not taking advantage of the architecture at that level then what's the point?

Finally, if you've built your [B|D]AL into the same assembly as your web service, well... I don't know what to tell ya there. You've obviously got some serious architectual decoupling to do and I wish you the best of luck.
</digression>

Now, on to Arne's problem...
Allthough, I believe we've found the source of your confusion, the OP
did say that DataSets were what he/she intended to use so your point
is mute.
C'mon now. Are you seriously trying to fault me for being confused about you *not talking about web services* on a web services newsgroup in response to a web services question? Shame on you. You can't possibly try to say I'm the one giving the sour advice here when I was clearly trying to help Arne understand the real choices available to him in web services rather than resorting to passing typeless xsd:any or, worse, xsd:string (which is essentially the XML equivalent of void*) around.
Again Drew, we are talking about situations where DataSets WILL be
used.

Yes, I clearly understood that given my detailed example of how the DataSet will be represented in schema (by default). In fact, I never doubted DataSets were being used here... it's just *how* they're going to be used that seems to have caused the confusion here. There in lies the problem with your suggestion and ensuing argument: the original author *was* talking about using them over webservices (more specifically on the wire, not intra/interprocess). The only thing anyone has to do to figure this out was read the first line of the original request for assistance:

"How do I pass a dataset to a webservices? I need to submit a shoppingcart from a pocket PC to a webservice."

Maybe that's why Arne didn't see your initial suggestion as a useful one and replied (rightfully so IMHO):

"That is the right answer to the wrong question."

So, Arne, I at least hope this discussion has been useful to you despite the alleged "confusion" . If you need more detail about how to get your DataSet to serialize to and from a specific XML schema, feel free to ask. As I said originally though, you might not even care about that if your writing the only software that is ever going to be a client to the service.

Later,
Drew

[Scott M.]

> Well, yeah, that sure might explain it. After all this is the

microsoft.publi c.dotnet.framew ork.**webservic es** newsgroup. :)
....And it is used by a WebMethod, of a WebService just not from the client
end, from the back-end that's all. Does that somehow not "qualify" as a
legitmate web service topic? Please!

What I am
proposing would be something that a webmethod would be calling deeper
in the n-tier of the server that is running the web service. You
don't use WSDL to get these layers communicating since they are both
part of the same assembly. You are under the impression I've been
describing a web service to web service client, which I have not.
So wait... let us pause to discuss this design for a second:

<digression level="moderate ">
If this is a deeper layer, why aren't you passing strong types (at least
DataSets) around at that point? Are you actually telling us that you're
passing strings of XML from a web method written in managed code to a data
layer also written in managed code and doing the parsing within that
layer? Forget losing strong typing at the web service layer, you seem to
have given that up at a lower level already.

I think you really need to go back and read the posts before you got
involved. I originally suggested that there were 2 ways (that I could think
of) to address the OP. The first was to pass the DataSet directly. The OP
said he's having problems doing that and wanted to take a look at my second
choice. I told the OP that if he wanted to use the first choice (DataSet),
we'd just need to see his code to determine what he's doing wrong.

The web service should be the one to convert the XML to strongly typed
data, or at the very least DataSet, before passing it on to the next
layer? I mean, that's usually the whole point of a Web Service/Method: to
act as a façade over a set of lower level systems. It's entire reason for
existence is to bridge the communication gap. If you're not taking
advantage of the architecture at that level then what's the point?
I am taking advantage of the Web Service in just the way you describe. Work
this backwards from the actual data source (in other words, assume the call
to the web service has already been made and this is how we return data back
through the web service)...

Data souce gives actual data to Data Layer (this is where we have a strongly
typed DataSet to hold that data)
Strongly Typed DataSet gives its actual data to a WebMethod
WebMethod (web service) gives its data to a web service client (serialized)
Client puts its data into a DataSet

The WebSevice could have a strongly typed dataset, but the most important
place for there to be one is in the Data Layer. From there it is very easy
to persist the structure and data types of the original data up the chan
either by passing a DataSet or by passing the XML and the XMLSchema data.
There is no risk in doing this because the client WILL receive the data in a
DataSet (either by populating the XMLSchema and XML data or by receiving a
DataSet with this information intact). I believe you are still thinking
about this thread backwards. The only thing we are saying about the web
service client here is that it will store its data in a DataSet. That
dataset will perform equally well if it gets its data via XMLSchema/Data or
just by receiving a DataSet.

Finally, if you've built your [B|D]AL into the same assembly as your web
service, well... I don't know what to tell ya there. You've obviously got
some serious architectual decoupling to do and I wish you the best of
luck.
</digression>
I'm not sure why you've been so adversarial here. Again, if you had read
the OP and the posts leading up to your first post, you would have seen that
I advocated a DataSet as the first choice. It's just really frustrating
that you keep wanting to tell me how I'm doing it wrong (and how you are the
one with all the correct answers) and how I don't understand how web
services, XML and DataSets work, when I believe it is you who isn't quite up
to speed on what we've been talking about here.

Now, on to Arne's problem...

Allthough, I believe we've found the source of your confusion, the OP
did say that DataSets were what he/she intended to use so your point
is mute.

C'mon now. Are you seriously trying to fault me for being confused about
you *not talking about web services* on a web services newsgroup in
response to a web services question? Shame on you.

Uh, yes since I am simply talking about the back end of a web method.
You can't possibly try to say I'm the one giving the sour advice here
Did I say that? Gee, I don't think I did. In fact, I don't dispute
anything you've said. I've just said that you are talking about a scenario
that we are not.
when I was clearly trying to help Arne understand the real choices
available to him
Pahleeeeese go back and read my 3rd post in this thread. I believe those
are "real" choices as well. And, as a matter of fact, I believe my FIRST
suggestion is the same as yours.
in web services rather than resorting to passing typeless xsd:any or,
worse, xsd:string (which is essentially the XML equivalent of void*)
around.
Well, I guess it's a good thing that I didn't recommend that either. Too
bad you can't read as well as you write.

Why are you being so rude and adversarial? Each time I go back and explain
what has already been said earlier in this thread, you respond with
something like "Oh, well, in that case...". No one has disputed what you've
said, I've only said that that's not the scenario that is being discussed.

Again Drew, we are talking about situations where DataSets WILL be
used.
Yes, I clearly understood that given my detailed example of how the
DataSet will be represented in schema (by default). In fact, I never
doubted DataSets were being used here... it's just *how* they're going to
be used that seems to have caused the confusion here.

By your own admission, I really think that you are the only one that's
confused.
There in lies the problem with your suggestion and ensuing argument: the
original author *was* talking about using them over webservices (more
specifically on the wire, not intra/interprocess). The only thing anyone
has to do to figure this out was read the first line of the original
request for assistance:

"How do I pass a dataset to a webservices? I need to submit a
shoppingcart from a pocket PC to a webservice."
Of course, if you had read the other posts, the OP stated that he couldn't
get that to work and wanted to give the XML road a try. But, you didn't do
that.

Maybe that's why Arne didn't see your initial suggestion as a useful one
and replied (rightfully so IMHO):

"That is the right answer to the wrong question."
Maybe. But after explaining the 2 scenarios, he decided that the XML road
might be worth it and thus, we are now talking about that, rather than the
original track. If you had just done a little more reading and a little
less preaching.....

So, Arne, I at least hope this discussion has been useful to you despite
the alleged "confusion" .
You said you were confused, no one else said anything about it.
If you need more detail about how to get your DataSet to serialize to and
from a specific XML schema, feel free to ask. As I said originally though,
you might not even care about that if your writing the only software that
is ever going to be a client to the service.

Again, I think the confusion is limited to you. I am really at a loss to
come up with an understanding of why someone who obviously didn't read the
thread would be so condecending, rude and want to position themself as the
one who understands what the rest of us don't.

You know these newsgroups are a great place for professionals and novices to
share thoughts, ideas and strategies. It is not a place for egos and
rudness. You could have made your point(s) in a much less adversarial way
and avoided the confusion on your part by simply asking for clarification,
rather than throwing down innuendos and bullying your point.

I wish you good luck (and perhaps some manners too).

[Arne]

Scott and Drew,

I am impressed by your spirited discussion. It may take me a while to try
out all of your suggestions.
Thanks.
Arne.

"Scott M." wrote:

Well, yeah, that sure might explain it. After all this is the
microsoft.publi c.dotnet.framew ork.**webservic es** newsgroup. :)

....And it is used by a WebMethod, of a WebService just not from the client
end, from the back-end that's all. Does that somehow not "qualify" as a
legitmate web service topic? Please!

What I am
proposing would be something that a webmethod would be calling deeper
in the n-tier of the server that is running the web service. You
don't use WSDL to get these layers communicating since they are both
part of the same assembly. You are under the impression I've been
describing a web service to web service client, which I have not.

So wait... let us pause to discuss this design for a second:

<digression level="moderate ">
If this is a deeper layer, why aren't you passing strong types (at least
DataSets) around at that point? Are you actually telling us that you're
passing strings of XML from a web method written in managed code to a data
layer also written in managed code and doing the parsing within that
layer? Forget losing strong typing at the web service layer, you seem to
have given that up at a lower level already.

I think you really need to go back and read the posts before you got
involved. I originally suggested that there were 2 ways (that I could think
of) to address the OP. The first was to pass the DataSet directly. The OP
said he's having problems doing that and wanted to take a look at my second
choice. I told the OP that if he wanted to use the first choice (DataSet),
we'd just need to see his code to determine what he's doing wrong.

The web service should be the one to convert the XML to strongly typed
data, or at the very least DataSet, before passing it on to the next
layer? I mean, that's usually the whole point of a Web Service/Method: to
act as a façade over a set of lower level systems. It's entire reason for
existence is to bridge the communication gap. If you're not taking
advantage of the architecture at that level then what's the point?

I am taking advantage of the Web Service in just the way you describe. Work
this backwards from the actual data source (in other words, assume the call
to the web service has already been made and this is how we return data back
through the web service)...

Data souce gives actual data to Data Layer (this is where we have a strongly
typed DataSet to hold that data)
Strongly Typed DataSet gives its actual data to a WebMethod
WebMethod (web service) gives its data to a web service client (serialized)
Client puts its data into a DataSet

The WebSevice could have a strongly typed dataset, but the most important
place for there to be one is in the Data Layer. From there it is very easy
to persist the structure and data types of the original data up the chan
either by passing a DataSet or by passing the XML and the XMLSchema data.
There is no risk in doing this because the client WILL receive the data in a
DataSet (either by populating the XMLSchema and XML data or by receiving a
DataSet with this information intact). I believe you are still thinking
about this thread backwards. The only thing we are saying about the web
service client here is that it will store its data in a DataSet. That
dataset will perform equally well if it gets its data via XMLSchema/Data or
just by receiving a DataSet.

Finally, if you've built your [B|D]AL into the same assembly as your web
service, well... I don't know what to tell ya there. You've obviously got
some serious architectual decoupling to do and I wish you the best of
luck.
</digression>

I'm not sure why you've been so adversarial here. Again, if you had read
the OP and the posts leading up to your first post, you would have seen that
I advocated a DataSet as the first choice. It's just really frustrating
that you keep wanting to tell me how I'm doing it wrong (and how you are the
one with all the correct answers) and how I don't understand how web
services, XML and DataSets work, when I believe it is you who isn't quite up
to speed on what we've been talking about here.

Now, on to Arne's problem...

Allthough, I believe we've found the source of your confusion, the OP
did say that DataSets were what he/she intended to use so your point
is mute.

C'mon now. Are you seriously trying to fault me for being confused about
you *not talking about web services* on a web services newsgroup in
response to a web services question? Shame on you.

Uh, yes since I am simply talking about the back end of a web method.

You can't possibly try to say I'm the one giving the sour advice here

Did I say that? Gee, I don't think I did. In fact, I don't dispute
anything you've said. I've just said that you are talking about a scenario
that we are not.

when I was clearly trying to help Arne understand the real choices
available to him

Pahleeeeese go back and read my 3rd post in this thread. I believe those
are "real" choices as well. And, as a matter of fact, I believe my FIRST
suggestion is the same as yours.

in web services rather than resorting to passing typeless xsd:any or,
worse, xsd:string (which is essentially the XML equivalent of void*)
around.

Well, I guess it's a good thing that I didn't recommend that either. Too
bad you can't read as well as you write.

Why are you being so rude and adversarial? Each time I go back and explain
what has already been said earlier in this thread, you respond with
something like "Oh, well, in that case...". No one has disputed what you've
said, I've only said that that's not the scenario that is being discussed.

Again Drew, we are talking about situations where DataSets WILL be
used.

Yes, I clearly understood that given my detailed example of how the
DataSet will be represented in schema (by default). In fact, I never
doubted DataSets were being used here... it's just *how* they're going to
be used that seems to have caused the confusion here.

By your own admission, I really think that you are the only one that's
confused.

There in lies the problem with your suggestion and ensuing argument: the
original author *was* talking about using them over webservices (more
specifically on the wire, not intra/interprocess). The only thing anyone
has to do to figure this out was read the first line of the original
request for assistance:

"How do I pass a dataset to a webservices? I need to submit a
shoppingcart from a pocket PC to a webservice."

Of course, if you had read the other posts, the OP stated that he couldn't
get that to work and wanted to give the XML road a try. But, you didn't do
that.

Maybe that's why Arne didn't see your initial suggestion as a useful one
and replied (rightfully so IMHO):

"That is the right answer to the wrong question."

Maybe. But after explaining the 2 scenarios, he decided that the XML road
might be worth it and thus, we are now talking about that, rather than the
original track. If you had just done a little more reading and a little
less preaching.....

So, Arne, I at least hope this discussion has been useful to you despite
the alleged "confusion" .

You said you were confused, no one else said anything about it.

If you need more detail about how to get your DataSet to serialize to and
from a specific XML schema, feel free to ask. As I said originally though,
you might not even care about that if your writing the only software that
is ever going to be a client to the service.

Again, I think the confusion is limited to you. I am really at a loss to
come up with an understanding of why someone who obviously didn't read the
thread would be so condecending, rude and want to position themself as the
one who understands what the rest of us don't.

You know these newsgroups are a great place for professionals and novices to
share thoughts, ideas and strategies. It is not a place for egos and
rudness. You could have made your point(s) in a much less adversarial way
and avoided the confusion on your part by simply asking for clarification,
rather than throwing down innuendos and bullying your point.

I wish you good luck (and perhaps some manners too).

[Arne]

Scott,
Once I use the 'Update Web Reference' feature in VS 2003, I could get my
program to compile with the right data type. The 'rebuild solution' feature
in VS 2003 does really rebuild the solution the way I had expected. The
dataset datatype now compiles OK.
Arne.

"Scott M." wrote:

If you are interested in the first approach, just let me see your code for
the 2 methods and I'll bet we can make it work.
"Arne" <Ar**@discussio ns.microsoft.co m> wrote in message
news:98******** *************** ***********@mic rosoft.com...

Scott,

Your second answer is very interesting and I will pursue it.
Your first answer doesn't compile on my computer.
Thanks.

Arne.

"Scott M." wrote:

Arne,

If you have data in a DataSet, you have a couple of choices:

1. Just pass the entire DataSet object to a web service web method that
takes a DataSet as a parameter. (I don't recommend this approach if the
DataSet will be passed between 2 machines in the process because of
efficiency).

2. Use the DataSet.GetXML method (which returns an XML string
representing
the DataSet) and pass that string to a web service web method. Then that
web method would declare a new DataSet and using the ReadXML method, it
could read the XML string into itself. You will need to load the XML
string
into an XMLDocument and then pass it to an XMLNodeReader so that it can
be
read into the DataSet using ReadXML.

"Arne" <Ar**@discussio ns.microsoft.co m> wrote in message
news:9E******** *************** ***********@mic rosoft.com...
> Scott,
> I reread your two posts, but I am not able to understand your answer.
> All
> I
> am interested in is a datatype to use when sending a dataset to a web
> services. Would that be an
> XMLDocument
> XMLElement
> XMLDataDocument
> String
> or some other hocus pocus.
> Arne.
>
> "Scott M." wrote:
>
>> Arne,
>>
>> Wow! Thanks for the attitude. Do you want to try again and read my
>> first
>> post and see that the answer you seek is in there?
>>
>> Hint: "the DataSet's GetXML and ReadXML methods".
>>
>> Perhaps you could think about what I wrote and try to see how it might
>> fit
>> into your situation.
>>
>> -Scott
>>
>>
>> "Arne" <Ar**@discussio ns.microsoft.co m> wrote in message
>> news:E7******** *************** ***********@mic rosoft.com...
>> > Scott,
>> > That is the right answer to the wrong question. I you you read my
>> > question
>> > you will find that I have a problem passing a dataset to a web
>> > services. I
>> > do
>> > not have a problem returning a dataset from a web services.
>> > Do you want to try again to get the right answer?
>> > Arne
>> >
>> > "Scott M." wrote:
>> >
>> >> You are probably better off using the DataSet's GetXML and ReadXML
>> >> methods.
>> >> In other words, the web service returns the xml from a DataSet as a
>> >> string.
>> >> This xml can then be very easily put back into a new DataSet.
>> >>
>> >>
>> >> "Arne" <Ar**@discussio ns.microsoft.co m> wrote in message
>> >> news:E1******** *************** ***********@mic rosoft.com...
>> >> > How do I pass a dataset to a webservices? I need to submit a
>> >> > shoppingcart
>> >> > from a pocket PC to a webservice.
>> >> > What is the right datatype?
>> >> > II have tried dataset as a datatype, but I can't get it to
>> >> > compile.
>> >> > <WebMethod()> _
>> >> > Public Function VerifySku(ByVal skus As XmlDataDocument ) As
>> >> > DataSet
>> >> >
>> >> > Test program :
>> >> > Dim cartSet As DataSet
>> >> > cartSet = ws.VerifySku(ca rtSet)
>> >> >
>> >> > Error:
>> >> > C:\Projects\Sho ppingCartWeb\Sh oppingCartTest\ Test.vb(37): Value
>> >> > of
>> >> > type
>> >> > 'System.Data.Da taSet' cannot be converted to '1-dimensional array
>> >> > of
>> >> > System.Object'.
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

[Drew Marsh]

Scott M. wrote:

Again, I think the confusion is limited to you. I am really at a loss
to come up with an understanding of why someone who obviously didn't
read the thread would be so condecending, rude and want to position
themself as the one who understands what the rest of us don't.

You know these newsgroups are a great place for professionals and
novices to share thoughts, ideas and strategies. It is not a place
for egos and rudness. You could have made your point(s) in a much
less adversarial way and avoided the confusion on your part by simply
asking for clarification, rather than throwing down innuendos and
bullying your point.

I wish you good luck (and perhaps some manners too).

Scott,

I'm sorry you feel that way, but you should take tech. discussions with a grain of salt. As for me asking for more clarification: from my point of view, you never explained yourself fully. When you get into a discussion, don't you think to yourself "hey, maybe I should be as detailed as possible so the other person understands where I'm coming from"? Your responses were very brief and lacked any real technical detail to help clarify your points. Hence leading to what you perceive as confusion on my part, but was really my attempt at interpretation.

As for innuendos and rudeness, I've been perfectly civil and never once was one of my posts not filed with some form of technical discussion. I never resorted to bashing you personally in any way, but yes I did call you out on the technical merits of your proposed solutions. As developers we're supposed to spar like this, it helps people who may not fully understand either side of the discussion. I could understand you perceiving my posts as purely rubbish and write me off as some troll if I wasn't also offering the technical advice that I clearly was attempting to offer. You'd see that I wasn't arguing with you as a person as much as I was arguing with your advice as a developer if you detached your personal feelings from the conversation.

Now, you say I didn't read the thread, well... I clearly read it since I quoted the most important part of the OP, in my previous message. Let's focus just on the post you made where I decided to jump into the thread and maybe that will help clear things up:

----

You offered up two solutions (paraphrased quotes):

1) "...Pass the DataSet between the two methods..."

Now you go on call to question the efficiency of this approach for some reason. It's the better solution in all actuality, but not the one you're really recommending for whatever reason. You're also still talking about web services here. You know at this point the OP is asking how to send something from a PocketPC to a web server. So you're right, I'm confused... I don't know when you made alleged switch to talking about backend systems. Clearly the question was about web method signatures posted in a webservices newsgroup. How were we not talking about a web method signature here? Help me understand your POV as I've helped you understand mine.

2) "...Turn the DataSet into a string using GetXml, pass it to the web method as string, turn it back into DataSet in the web method..."

That's the one that made me reply. What does that do for anyone in this situation? Spar with me on the technical merits of that suggestion alone and we can put an end to this. Tell me what you perceive the difference as being between #1 and #2. How is that more efficient? It's not. It's actually the *same exact data* going over the wire except now it's changed the signature from some semi-structured XML form (xsd:any, but at least it's well-formed XML) to a straight up opaque string. Not only that but now you made the guy do more work to get the same results with less strong typing. In fact, it's going to be LESS efficient because you either need to stuff the string in a CDATA section or you need to encode all the special characters in the DataSet XML string, bloating it way bigger than it ever needed to be. So yeah, I'm confused here. Why would you even suggest this?

----

In you're last post, you said:

"I originally suggested that there were 2 ways (that I could think of) to address the OP. The first was to pass the DataSet directly. The OP said he's having problems doing that and wanted to take a look at my second choice. I told the OP that if he wanted to use the first choice (DataSet), we'd just need to see his code to determine what he's doing wrong."

Ok, good. Why didn't you just do that then? Why would you give the bad advice of turning it into a string when you know it's supposed to work as a DataSet? Is that really helping anyone understand? In my book that's classified as hacking. I like to help people understand. I like to make sure they understand the decisions they are making. Which is why I posted:

"Maybe I'm not reading this right, but are you proposing he send it as a string (xsd:string) rather than as a structured XML document? I hope not, because that approach would completely misses the point of XML altogether."

My initial assessment of your suggested hack (#2) was correct and please note I even entered the conversation nicely by erring on the side of caution that maybe you didn't mean what you said. By your own admission in that last post, you were telling him to pass it through the web service as a string. Then you tried to come back and tell me that the data would be strongly typed, which it clearly would/could not be in terms of the web method and I continued to call you on it for the sake of helping anyone viewing the discussion understand what they would be getting into if they chose to go that route.

Please don't take this personally man, I'm not out to get you. However, I will stand by my technical knowledge on this subject and can't just sit by and watch bad technical solutions be proposed in a forum where we're supposed to be helping people understand and do things the right way. It was clear in his first post he was using XmlDataDocument so the first suggestion should have been to change that signature. Recommending he pass a string without first trying to work out his issues with DataSet was a bad solution. That's all I initially set out to argue.

Cheers,
Drew

P.S. As I finished reviewing the content of this post, I noticed that Arne has gotten DataSet to work (as it should have from the get go) so our discussion is now rendered moot and only serves to help others who face this decision from this point on in history. Now I can try and explain that passing DataSet without strongly typing your WSDL by hand is the next worst thing to passing a string! ;P

[Scott M.]

> I'm sorry you feel that way, but you should take tech. discussions with a

grain of salt.
A technical discussion I can take with a grain of salt. Being told flat out
that I was wrong and don't understand XML and web services by someone who
doesn't have the full story is something else.
As for me asking for more clarification: from my point of view, you never
explained yourself fully. When you get into a discussion, don't you think
to yourself "hey, maybe I should be as detailed as possible so the other
person understands where I'm coming from"? Your responses were very brief
and lacked any real technical detail to help clarify your points.
I was explaining my suggestion to the OP, not you. I felt comfortable that
the OP had the information that he was seeking. He wasn't looking for a
dissertaion, he was looking for suggestions. This is what I was providing
and I have to say, while he started out not quite following me, we got over
that bump (without your "help") and were on our way to a solution (without
your "help").
Hence leading to what you perceive as confusion on my part, but was really
my attempt at interpretation.
Look, you are the one that flat out said you were confused. Stop saying
that I am perceiving something you, yourself admitted.

As for innuendos and rudeness, I've been perfectly civil and never once
was one of my posts not filed with some form of technical discussion. I
never resorted to bashing you personally in any way, but yes I did call
you out on the technical merits of your proposed solutions.
You have been rude. Jumping into the middle of a conversation without all
the facts and telling the OP and me that my approach is wrong and
questioning my knowledge without finding out what is going on is rude. I
think I learned that in kindergarten.
As developers we're supposed to spar like this, it helps people who may not
fully understand either side of the discussion.
As humans, we are supposed to show others respect. You haven't shown any.
I've mentioned on more than one occassion that your technical descriptions
have been correct, but that you have not fully understood the scenario we
were discussing, yet you continuously came back with more technical details
without simply listening to what I was saying. I even think my first
response to you said something like "I think you are misunderstandin g what
I'm suggesting." You responded forcefully with something like "I understand
100% and you are wrong." That's not technical sparring, that's just rude.
I could understand you perceiving my posts as purely rubbish and write me
off as some troll if I wasn't also offering the technical advice that I
clearly was attempting to offer. You'd see that I wasn't arguing with you
as a person as much as I was arguing with your advice as a developer if you
detached your personal feelings from the conversation.
And, I would accept that statement as true if it weren't for you continuing
to ignor me when I would say that your tech. descriptions are correct, but
you are misunderstandin g the context of the discussion and my pleas for you
to go back and familiarize yourself with what we are talking about. Again,
that is just common sense and common courtesey.

Now, you say I didn't read the thread, well... I clearly read it since I
quoted the most important part of the OP, in my previous message. Let's
focus just on the post you made where I decided to jump into the thread
and maybe that will help clear things up:

----

You offered up two solutions (paraphrased quotes):

1) "...Pass the DataSet between the two methods..."

Now you go on call to question the efficiency of this approach for some
reason. It's the better solution in all actuality, but not the one you're
really recommending for whatever reason. You're also still talking about
web services here. You know at this point the OP is asking how to send
something from a PocketPC to a web server. So you're right, I'm
confused... I don't know when you made alleged switch to talking about
backend systems. Clearly the question was about web method signatures
posted in a webservices newsgroup. How were we not talking about a web
method signature here? Help me understand your POV as I've helped you
understand mine.

2) "...Turn the DataSet into a string using GetXml, pass it to the web
method as string, turn it back into DataSet in the web method..."

That's the one that made me reply. What does that do for anyone in this
situation? Spar with me on the technical merits of that suggestion alone
and we can put an end to this. Tell me what you perceive the difference as
being between #1 and #2. How is that more efficient? It's not. It's
actually the *same exact data* going over the wire except now it's changed
the signature from some semi-structured XML form (xsd:any, but at least
it's well-formed XML) to a straight up opaque string. Not only that but
now you made the guy do more work to get the same results with less strong
typing. In fact, it's going to be LESS efficient because you either need
to stuff the string in a CDATA section or you need to encode all the
special characters in the DataSet XML string, bloating it way bigger than
it ever needed to be. So yeah, I'm confused here. Why would you even
suggest this?
Actually it is not the same. To serialize a DataSet takes more CPU time
that to just take the XML.
I suggested it as an alternative because the OP said he was having problems
passing a DataSet.
I've also stated that you can pass the schema as well as the data so no data
integrity is lost.

And, perhaps most importantly (again), my problem with you hasn't been your
techical descriptions (I find it interesting how you keep coming back to a
point not in dispute). My problem has been your unwillingness to get an
idea of the circumstances of the situation. Surely you will admit that
there is always more than one way to get the job done and different
circumstances warrant different approaches? But, you wouldn't hear any of
that. When you finally started to, you admitted that what I was saying made
sense. Then you got off subject (away from your tech. descriptions) and had
to somehow prove you were still right by quesitoning my comments in this
particular NG. Again, had you taken the time to familiarize yourself with
the conversation, you would have know we were talking about the back-end
processing of, guess what? A WEB SERVICE.


----

In you're last post, you said:

"I originally suggested that there were 2 ways (that I could think of)
to address the OP. The first was to pass the DataSet directly. The OP said
he's having problems doing that and wanted to take a look at my second
choice. I told the OP that if he wanted to use the first choice (DataSet),
we'd just need to see his code to determine what he's doing wrong."

Ok, good. Why didn't you just do that then? Why would you give the bad
advice of turning it into a string when you know it's supposed to work as
a DataSet? Is that really helping anyone understand? In my book that's
classified as hacking. I like to help people understand. I like to make
sure they understand the decisions they are making.
First of all, you need to get one thing VERY clear (since you want to be all
technical): There is absolutley nothing wrong (hence NOT bad advice) with
passing xml schema and xml data around (in fact, if you understand what a
web service is, then you'd kinda know that). Your initial dislike of this
approach was that you couldn't know what kind of client you were going to
have and so (in those cases), my suggestion would be a bad idea. You know
what? In that case, you would be right, but that wasn't the case being
discussed and so, you were not right. You admitted as much so would you
please be technically correct and stop saying that passing data around as
xml and xml schema is "bad" or "wrong", it is neither. In fact, it's kinda
the whole point of XML.

You may not prefer to pass data this way, but that is your preference. I do
work with one of the world's largest insurance companies and they have a
corporate development standard that says that data comes out of the database
into a strongly typed dataset, gets turn into XML right there and then from
there on is passed as xml schema and xml data until it is finally placed
back into a dataset in the UI layer. This company has worked with MS
engineers since early betas of .NET to develop its data handling practices
and for efficiency reasons has determined that this is a better approach
than passing datasets all over the place. Now, you may disagree and that's
fine, but it doesn't mean the practice is not sound.
Which is why I posted:

"Maybe I'm not reading this right, but are you proposing he send it as
a string (xsd:string) rather than as a structured XML document? I hope
not, because that approach would completely misses the point of XML
altogether."
And which is why I replied:
"This approach works for passing the DataSet schema as well. We can the
DataSet's GetXML and we can use the DataSet's GetXMLSchema to send and then
we can use the DataSet's ReadXMLSchema as well as ReadXML to re-populate."

This is what I'm talking about. After that, you agreed and move on to
something else you felt you could prove me wrong on: whether I posted this
in the right NG, come on now, that's pretty obvious you were reaching for
something to put me down on.

My initial assessment of your suggested hack (#2) was correct and please
note I even entered the conversation nicely by erring on the side of
caution that maybe you didn't mean what you said. By your own admission in
that last post, you were telling him to pass it through the web service as
a string. Then you tried to come back and tell me that the data would be
strongly typed, which it clearly would/could not be in terms of the web
method and I continued to call you on it for the sake of helping anyone
viewing the discussion understand what they would be getting into if they
chose to go that route.
I have no idea what in the world you are talking about. This is you being
rude again. There is no hack involved. I've explained myself over and over
and the process I described is perfectly sound. You are absolutely
incorrect when you say that the data's integrity wouldn't be there at the
end of the data's journey. This is flat out wrong. Either you don't
understand how this process works or you STILL don't understand what I'm
suggesting. There is NO question though that you are mistaken as I have
used this model for several years and know for a fact that the resulting
dataset contains data with all of its structure intact. Drew, you can say
I'm wrong in 26 languages and as loud as you want, but it just isn't true.
What's interesting is that now you are saying that my solution wouldn't
work, when earlier, you said: "Well, yeah, that sure might explain it.",
agreeing with me that for the circumstance, it was a perfectly viable
scenario.
Please don't take this personally man, I'm not out to get you. However, I
will stand by my technical knowledge on this subject and can't just sit by
and watch bad technical solutions be proposed in a forum where we're
supposed to be helping people understand and do things the right way.
How can I not take it personally?! I have suggested a perfectly correct and
viable solution (YOU: "Well, yeah, that sure might explain it.") that has
been tried and tested for years, yet to continue to call it a "hack" which
it most certainly isn't. What do you think XML was created for? How in the
world do you think data was passed around the web before 2/02 when MS
unvield the DataSet? Come on Drew, you are telling me that an industry
standard for moving data around the web is not how to move data around the
web? Who's kidding who here? There's nothing wrong with your knowledge and
there is nothing wrong with mine. I take offense at you saying so.
It was clear in his first post he was using XmlDataDocument so the first
suggestion should have been to change that signature. Recommending he pass
a string without first trying to work out his issues with DataSet was a
bad solution. That's all I initially set out to argue.

Again, no it wasn't. I did EXACTLY what you said (but you seem to have
ignored that because you just can't stand to admit you were wrong).

I've wasted enough of my life on you Drew. It's obvious you really not out
to help anyone or anything but your ego. You have been incredibly rude, to
some degree ignorant (of what was going on before you threw your 2 cents
in), mostly hostile and ultimately not very helpful. You've boasted about
your technical knowledge. And, while I don't doubt your skills & knowledge,
you've shown short-sightedness and an unwillingness to see the big picture.
You've said that my solution was correct for the circumstance and then
called it a "hack" and "bad advice".

If you can't be honest (at least with yourself) and see these things, then
you can never grow beyond who you are today. I personally don't want to
deal with a person such as yourself any longer, so I wish you good luck in
your endeavors.

Goodbye.