Hi Folks,

Just felt a compelling urge to rant about how poor a job MS has done
accomodating xml schema in the dataset.

First, using the dataset's ReadXmlSchema() method to supply your own
hand-generated scheam, it creates the datasets but try returning the schema
using the WriteXmlSchema() method or simply return xml after populating the
datatables...

You don't get the same schema! It actually uses the id in your
hand-generated schema as the new top-level element ?!?

IF I WANTED MY XML REPRESENTED THAT WAY I WOULD HAVE DESIGNED MY SCHEMA AS
SUCH!!!
....

!!!!!!!!!!!!!!

.... no really, ... !!!!!!!!!!!!!!

Next, amongst many other problems, don't use an id in your hand-generated
schema that is the same name as the top-level element: it will actually
create duplicate top-level elements - ug.

Or, how about the fact that it actually it strips your own namespacing
completely. That is certainly the biggest slap in the face.

Oh, and forget about importing other schemas within your hand-generated
schema - it's totally oblivious.

Unbelievable!!!

Signed,

P.O.'d

Rein,

If your purpose is more than ranting, I'd suggest you clean this up and
submit it to the wish (afaik, you can do a wishlist search on
www.msdn.microsoft.com). I know XML in general is on their radar.

Although I have to wonder whether we want to output input schemas. Dunno.
I'd suggest you explain why having .NET store this specific schema is
important. Obviously a lot of schemas can match a particular set of data.

--
Kathleen (MVP-VB)



"Rein Petersen" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Folks,
>
> Just felt a compelling urge to rant about how poor a job MS has done
> accomodating xml schema in the dataset.
>
> First, using the dataset's ReadXmlSchema() method to supply your own
> hand-generated scheam, it creates the datasets but try returning the
schema
> using the WriteXmlSchema() method or simply return xml after populating
the
> datatables...
>
> You don't get the same schema! It actually uses the id in your
> hand-generated schema as the new top-level element ?!?
>
> IF I WANTED MY XML REPRESENTED THAT WAY I WOULD HAVE DESIGNED MY SCHEMA AS
> SUCH!!!
> ...
>
> !!!!!!!!!!!!!!
>
> ... no really, ... !!!!!!!!!!!!!!
>
> Next, amongst many other problems, don't use an id in your hand-generated
> schema that is the same name as the top-level element: it will actually
> create duplicate top-level elements - ug.
>
> Or, how about the fact that it actually it strips your own namespacing
> completely. That is certainly the biggest slap in the face.
>
> Oh, and forget about importing other schemas within your hand-generated
> schema - it's totally oblivious.
>
> Unbelievable!!!
>
> Signed,
>
> P.O.'d
>
>
>

Hi Everyone,

Please accept my apologies for the rant. Anyway, Kathleen, you had asked why
we might want to "output input schemas".

Well, it's a matter of serialization (late-bound that is). Using developer
supplied (mapping) schemas, I am trying to build a platform that can read
and perform
operations on the data for which instances (xml docs or db mapping -> xml
doc) are to comply. The dataset, with it's support for child tables
(elements), is particularly suited for this task.
Except, the output xml is not nearly close enough to what the input schema
(used to create the datatables, relationships, and constraints) has defined.

The name of the dataset should not be found as a top-level element. It is
the developer's responsibility to ensure that the top-level table has a
single entry for outputing well-formed xml (a single top-level root element
that is)

Anyway, I only ranted because now they've gone way too far based on a botch
(even submitted .NET to ECMA) so several developers will likely "blindly"
use it and now we're stuck with it. It would make a little more sense for MS
to ease back on charging ahead and spend more time with the public on
matters relating to classes that involve xml.

I would have loved to had a say on the matter. But now it's too late and I
might as well build the whole thing myself (doesn't make much sense
inheriting a bloated set of classes that I must overide practically all the
methods and attributes).

Rein

Rein,

Glad to hear it, but I meant if you submit a wish you should explain why you
want the feature you are asking for.

Understanding where you are coming from - yes, you want to write your own
serialization for many data scenarios. The purpose of the ADO.NET default
serialization is a really simple solution where there is ADO.NET on both
ends. It is intended more to force your schema into a single ADO.NET
standard schema. This does have benefits. It allows you to bring data in
using any (OK, many) formats and then shove it out knowing it will be
understood as an ADO.NET dataset. And you can do that hardly knowing what
the word serialization means.

OTOH, a reasonable approach would be to make it easier for you to provide
your own serilziation for datasets.

--
Kathleen (MVP-VB)



"Rein Petersen" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> Hi Everyone,
>
> Please accept my apologies for the rant. Anyway, Kathleen, you had asked
why
> we might want to "output input schemas".
>
> Well, it's a matter of serialization (late-bound that is). Using developer
> supplied (mapping) schemas, I am trying to build a platform that can read
> and perform
> operations on the data for which instances (xml docs or db mapping -> xml
> doc) are to comply. The dataset, with it's support for child tables
> (elements), is particularly suited for this task.
> Except, the output xml is not nearly close enough to what the input schema
> (used to create the datatables, relationships, and constraints) has
defined.
>
> The name of the dataset should not be found as a top-level element. It is
> the developer's responsibility to ensure that the top-level table has a
> single entry for outputing well-formed xml (a single top-level root
element
> that is)
>
> Anyway, I only ranted because now they've gone way too far based on a
botch
> (even submitted .NET to ECMA) so several developers will likely "blindly"
> use it and now we're stuck with it. It would make a little more sense for
MS
> to ease back on charging ahead and spend more time with the public on
> matters relating to classes that involve xml.
>
> I would have loved to had a say on the matter. But now it's too late and I
> might as well build the whole thing myself (doesn't make much sense
> inheriting a bloated set of classes that I must overide practically all
the
> methods and attributes).
>
> Rein
>
>