P
Peter R Lynch
After reading about typed datasets I thought they would be perfect for
accepting the complex data in a web service I am writing. I set about
defining my schema in the VS XML designer, happily let VS do the code
generation, and wrote a shell web method to accept it as a parameter.
I then set about beginning to test how it responded to a variety of
good and bad inputs.
Before I get to my gripes and questions, here is what I assumed typed
datasets would do for me:
Define the complete structure of my dataset to include enumerations,
required elements (Tables, Fields, etc), Min and Max constraints, plus
any other (reasonable) data related construct XSD cared to define. I
reasoned why not let the dataset do the heavy lifting of data
validation for me. Since the web service might be accessed by other
then .NET clients, I figured after looking at the XML the dataset
generated (just the XML, not the embedded schema, etc) that it
wouldn't be too complex for others to generate the XML needed to use
the method (as opposed to writing 2 or more methods for separate
client types). This way I could work with a dataset that can do all
those neat dataset things and not have to transpose XML into a dataset
or some other data structure.
Here is what I found (using the MS SOAP 3.0 toolkit as a client):
1. The typed dataset does no validation...none. I can send whatever
XML (no embedded schema) I like to the method and my typed dataset
happily accepts it. I can add non-existing tables, non-existing
fields, incorrect data (as far as the schema goes) and all is accepted
without a peep. It seems the typed dataset will generate whatever
schema it wants based on whatever it is sent. Now I would expect that
from an untyped dataset but it seems counter to the whole reason for
having a typed dataset in the first place, that is, to define what the
dataset is or isn't! I would expect as the web method de-serializes
the incoming XML, the dataset should perform some sort of validation
against the typed dataset schema, shouldn't it?
2. Additionally, even when the basic schema of the XML is correct,
many of the XSD data restriction constructs, such as enumeration,
minLength, minOccurs, and maxOccurs don't seem to apply at all. I now
know this is something that is widely understood and MS is working on
(mmmmm).
3. So I thought, well I'll just validate the XML against the original
XSD generated and continue on. What a butt numbing experience that
was. I finally got it working after slogging through dozens of .NET
XML examples here and in other places.
After doing all this work I started to feel that I was missing
something critical. That it shouldn't be this hard. Can anyone tell me
that it isn't? That I am missing a setting somewhere that will make a
typed dataset actually validate the way I assumed it would? Even
though I did finally get it to validate properly against its XSD file,
a simpler, more elegant approach is what I'm after. Thanks!
accepting the complex data in a web service I am writing. I set about
defining my schema in the VS XML designer, happily let VS do the code
generation, and wrote a shell web method to accept it as a parameter.
I then set about beginning to test how it responded to a variety of
good and bad inputs.
Before I get to my gripes and questions, here is what I assumed typed
datasets would do for me:
Define the complete structure of my dataset to include enumerations,
required elements (Tables, Fields, etc), Min and Max constraints, plus
any other (reasonable) data related construct XSD cared to define. I
reasoned why not let the dataset do the heavy lifting of data
validation for me. Since the web service might be accessed by other
then .NET clients, I figured after looking at the XML the dataset
generated (just the XML, not the embedded schema, etc) that it
wouldn't be too complex for others to generate the XML needed to use
the method (as opposed to writing 2 or more methods for separate
client types). This way I could work with a dataset that can do all
those neat dataset things and not have to transpose XML into a dataset
or some other data structure.
Here is what I found (using the MS SOAP 3.0 toolkit as a client):
1. The typed dataset does no validation...none. I can send whatever
XML (no embedded schema) I like to the method and my typed dataset
happily accepts it. I can add non-existing tables, non-existing
fields, incorrect data (as far as the schema goes) and all is accepted
without a peep. It seems the typed dataset will generate whatever
schema it wants based on whatever it is sent. Now I would expect that
from an untyped dataset but it seems counter to the whole reason for
having a typed dataset in the first place, that is, to define what the
dataset is or isn't! I would expect as the web method de-serializes
the incoming XML, the dataset should perform some sort of validation
against the typed dataset schema, shouldn't it?
2. Additionally, even when the basic schema of the XML is correct,
many of the XSD data restriction constructs, such as enumeration,
minLength, minOccurs, and maxOccurs don't seem to apply at all. I now
know this is something that is widely understood and MS is working on
(mmmmm).
3. So I thought, well I'll just validate the XML against the original
XSD generated and continue on. What a butt numbing experience that
was. I finally got it working after slogging through dozens of .NET
XML examples here and in other places.
After doing all this work I started to feel that I was missing
something critical. That it shouldn't be this hard. Can anyone tell me
that it isn't? That I am missing a setting somewhere that will make a
typed dataset actually validate the way I assumed it would? Even
though I did finally get it to validate properly against its XSD file,
a simpler, more elegant approach is what I'm after. Thanks!