Controlling XML serialization sequence
Mark Waser
I have several planned applications that need to output XML governed by
existing schemas. These schemas all have specific element ordering. Short
of an XSLT transformation step (involving extra programming time/maintenance
and run-time computational resources), is there any way in which to control
element ordering?
Note 2: It seems really ludicrous to me that the output generated from a
dataset defined by a schema will not pass validation against that schema
because the dataset output does not have the correct order.
Christoph Schittko
the XML conforming to the schema.
HTH,
--
Christoph Schittko
Software Architect
"Mark Waser" <mwa...@mwaser.com> wrote in message
news:OGQt9k5bCHA.1480@tkmsftngp12...
Mark Waser
I'm afraid I don't understand your post. The only XMLSerialization
classes that I see in the Help are XMLSerializationRead and
XMLSerializationWrite which are marked "This type supports the .NET
Framework infrastructure and is not intended to be used directly from your
code." I also see the IXMLSerializable Interface but it is marked the same
way.
Also, I'm not sure why you don't like DataSets, particularly since they
have a built-in WriteXML method (granted, it doesn't sort correctly);
however, I'm also having the same problem that classes I'm creating for
WebMethods also sort in no order that I can comprehend (it's not
alphabetical, nor the order in my source file, nor anything else I can
determine).
Could you give me a pointer to what you're talking about?
Thanks.
Mark
"Christoph Schittko" <ChristophDo...@austin.rr.com> wrote in message
news:#1iJ445bCHA.2468@tkmsftngp10...
Christoph Schittko
I am impartial to DataSets, ... what I was trying to say though, is that you
can use XmlSerialization to parse an XML document instead of a DataSet if
you need to make sure that elements are written in a certain order. That, of
course, works only if you don't need all the other functionality of the
DataSet.
With XmlSerialization you define classes that map to XML types, defined by
an XML schema. You can either create the classes by hand or from an XML
schema with the XSD.exe tool that ships with the Framework SDK. Once you
have these classes you can transform their state into an XML document or
parse an XML document into objects with the XmlSerializer from the
System.Xml.Serialization namespace.
You can check the framework docs for more details on Xml Serialization and
the XmlSerializer class. Maybe they work in your particular scenario.
HTH,
Christoph Schittko
"Mark Waser" <mwa...@mwaser.com> wrote in message
news:Oy6YW39bCHA.2592@tkmsftngp09...
Mark Waser
(Note: Sorry I'm taking so long to respond but I'm trying out
everything you suggest rather than wasting your time . . . . :-)
I've tried creating classes by hand. The order of serialization (of
properties) appears to be random. In fact, I copied code from one web
service to another and ended up with a different serialization order in the
second web service than I had seen from the first web service yesterday.
Then, when I immediately went back to the first web service, I found that
the order of serialization for that web service, which I had not changed at
all, had changed from yesterday . . . . This does not give me a warm fuzzy,
at all. I'm trying to think if there is anything that I could have done to
trigger such a change (as I have a print-out from yesterday, so I have
proof-positive that the order is different) but I don't think I have changed
anything and even if so, I still can't figure out what determines the order.
It is neither alphabetical nor the order of the properties in my class nor
anything else I can determine.
I used the XSD.exe tool to create classes from a schema. I noticed that
the tool always creates public fields which are then used for the
serialization instead of get/set properties. Referring back to your
newsgroup conversation with Corey Manczuk on 10/2, you said both
"Unfortunately, there is no way to control the order with V1.0." and "The
current implementation serializes public fields in the order they appear in
the class definition before the public properties (also in the order they
appear in the class).". These statements would seem to be contradictory
since they seem to imply that you CAN control the order of serialization by
controlling the order of the public fields and/or controlling the order of
the public properties AND not using both at once (i.e. make it so you use
either all public fields or all public properties). The parentheses after
the second statement also seems to be wrong since I can assure you that (at
least in my case) the order does not match the order of my properties in the
class.
When I switched all of my properties to public fields (somewhat
problematical from a safety point of view), it DOES appear as if the order
of public fields (as opposed to properties) DOES affect the order of
serialization (though I haven't tried it on any complicated cases that
involve using classes as public variables). My remaining questions are:
1. Can I count on this behavior to continue (I didn't like it when my
service changed it's order from day to day - that's REALLY scary and almost
unfathomable)?
2. Is there any way in which public properties can be made to behave the
same way?
By the way, I've previously noticed with DataSets that the behavior is
similar in that the order is as specified in the schema EXCEPT that all
simple types are done first in the proper order and all complex types are
done second in the proper order (comprehensible behavior but absolutely
useless when you're dealing with a publicly controlled schema - - ONIX in my
case). It seems that Microsoft has made a huge error in this and also in
not serializing in order of public properties in the hand-written case. If
you could pass this on for future enhancement . . .
Does all this make sense or am I missing something here?
Mark
"Christoph Schittko" <christophdo...@austin.rr.com> wrote in message
news:esbyZLAcCHA.1296@tkmsftngp12...
Christoph Schittko
> all, had changed from yesterday . . . . This does not give me a warm
fuzzy,
Understandable, but I have never seen that before. In my cases my XML format
comes out the way I expect it. Granted, I keep my serialization classes
simple, mostly with fields only and, if possible, without any methods, so I
can regenerate them when the schema changes. Maybe it just got lucky with
the schemas I was using. Can you be more specific on what types are not
ordered correctly? How are you serializing your objects?
Still, the fields are serialized in the order they appear in the file.
> I used the XSD.exe tool to create classes from a schema. I noticed
that
> the tool always creates public fields which are then used for the
> serialization instead of get/set properties. Referring back to your
> newsgroup conversation with Corey Manczuk on 10/2, you said both
> "Unfortunately, there is no way to control the order with V1.0." and "The
> current implementation serializes public fields in the order they appear
in
> the class definition before the public properties (also in the order they
> appear in the class).".
There were some postings from MS somewhere indicating that it might change
some time down the road. Personally, I'd very much appreciate if I would not
have to keep my serialization classes that simple and if I could mix
properties and fields without affecting the order.
> These statements would seem to be contradictory
> since they seem to imply that you CAN control the order of serialization
by
> controlling the order of the public fields and/or controlling the order of
> the public properties AND not using both at once (i.e. make it so you use
> either all public fields or all public properties). The parentheses after
> the second statement also seems to be wrong since I can assure you that
(at
> least in my case) the order does not match the order of my properties in
the
> class.
Hasn't happened for me. The XmlSerializer would be worthless if you couldn't
control the order since, as you know, many XML model groups require a
certain order of element.
> involve using classes as public variables). My remaining questions are:
> 1. Can I count on this behavior to continue (I didn't like it when my
> service changed it's order from day to day - that's REALLY scary and
almost
> unfathomable)?
I count on it and I would hope that any changes in the future will not
affect this. Given what's been written about side-by-side installations,
that may mean that your apps are going to be stuck at V1.x. But right now
that's anyone's guess. I don't even know if coding on the XML stuff for V2.0
has started yet.
> 2. Is there any way in which public properties can be made to behave the
> same way?
To be honest, I don't even know why this is happening in the first place.
It's been consistent for me.
> By the way, I've previously noticed with DataSets that the behavior is
> similar in that the order is as specified in the schema EXCEPT that all
> simple types are done first in the proper order and all complex types are
> done second in the proper order (comprehensible behavior but absolutely
> useless when you're dealing with a publicly controlled schema - - ONIX in
my
> case).
Same as in the above case. So far I got lucky, I guess, but I haven't done
nearly as much with DataSets as I have with XmlSerialization? My question
here though is: How are you filling the DataSet and how are you specifying
the DataSet's schema? Are you calling ReadSchema() or are you using a typed
DataSet ?
> It seems that Microsoft has made a huge error in this and also in
> not serializing in order of public properties in the hand-written case.
If
> you could pass this on for future enhancement . . .
You can provide product feedback on the MS website [1] , but I know that
there are a few MS guys reading this group as well.
HTH,
Christoph Schittko
Christoph Schittko
http://register.microsoft.com/mswish/suggestion.asp?from=cu&fu=%2Fisapi%2Fgo
mscom%2Easp%3Ftarget%3D%2Fmswish%2Fthanks%2Ehtm
--
Christoph Schittko
Software Architect
"Christoph Schittko" <ChristophDo...@austin.rr.com> wrote in message
news:eDKxZUTcCHA.1872@tkmsftngp12...
Mark Waser
CS>> Can you be more specific on what types are not ordered correctly? How
are you serializing your objects?
Here is my code and the results.
======= Begin Code
<WebMethod()> Public Function InvLevel(ByVal ProductID As Integer) As
inventory
Dim conn As SqlConnection, cmdSP As SqlCommand
Dim parm As SqlParameter, reader As SqlDataReader
Dim tstr As String
Dim inv As inventory = New inventory()
Dim prod As product = New product()
conn = New SqlConnection(connString)
conn.Open()
cmdSP = New SqlCommand("prod_invLevel", conn)
cmdSP.CommandType = CommandType.StoredProcedure
cmdSP.Parameters.Add("@ProductID", ProductID)
reader = cmdSP.ExecuteReader(CommandBehavior.SingleRow)
reader.Read()
prod.productID = reader.Item(0)
prod.available = reader.Item(1)
prod.ISBN = reader.Item(2)
prod.title = reader.Item(3)
'prod.author = reader.Item(4)
inv.product = prod
InvLevel = inv
End Function
Public Class inventory
Private xProd As product
Public Property product() As product
Get
Return xProd
End Get
Set(ByVal Value As product)
xProd = Value
End Set
End Property
End Class
Public Class product
Private xID As Integer, xAvail As Integer
Private xISBN As String, xTitle As String, xAuthor As String
Public Property productID() As Integer
Get
Return xID
End Get
Set(ByVal Value As Integer)
xID = Value
End Set
End Property
Public Property available() As Integer
Get
Return xAvail
End Get
Set(ByVal Value As Integer)
xAvail = Value
End Set
End Property
Public Property ISBN() As String
Get
Return xISBN
End Get
Set(ByVal Value As String)
xISBN = Value
End Set
End Property
Public Property title() As String
Get
Return xTitle
End Get
Set(ByVal Value As String)
xTitle = Value
End Set
End Property
Public Property author() As String
Get
Return xAuthor
End Get
Set(ByVal Value As String)
xAuthor = Value
End Set
End Property
End Class
======= End Code, Begin Results
<?xml version="1.0" encoding="utf-8" ?>
- <inventory xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://tempuri.org/">
- <product>
<available>1030</available>
<title>TARRANT CHRONICLES THE</title>
<ISBN>0972233601</ISBN>
<productID>65959</productID>
</product>
</inventory>
======= End Results
Can you see any correlation between my code and the ordering? I am lost
here.
CS>> How are you filling the DataSet and how are you specifying the
DataSet's schema? Are you calling ReadSchema() or are you using a typed
DataSet ?
When doing the DataSet thing, I've always used a typed dataset created from
the correct schema, filled it with data from my database using DataAdapters,
and serialized it by using DataSet.WriteXML.
It is 100% consistent in doing everything in the order specified in the
schema EXCEPT that all simple elements (i.e. fields in a given data set) are
extracted and placed before all complex elements (i.e. fields that are
extracted from child datasets).
Thanks.
Mark
"Christoph Schittko" <ChristophDo...@austin.rr.com> wrote in message
news:eDKxZUTcCHA.1872@tkmsftngp12...
Christoph Schittko
The good news and the bad news is I repro'd it with your code ... the order
is MESSED up. You can already see it when you look the at the WSDL generated
for your web service. Conclusion: the meta data for your class does not
match your code.
Then I did some more research. Same code in C# works just peachy, so the
XmlSerializer doesn't seem to be at fault ... it looks more like the VB.Net
compiler messes up the order of the properties.
Then I tried the VB code against the V1.1 beta bits ... don't know if I am
at liberty to disclose the results, but the framework SDK beta is public.
You may want to take a look.
HTH,
--
Christoph Schittko
Software Architect
"Mark Waser" <mwa...@mwaser.com> wrote in message
news:uiaViEUcCHA.2224@tkmsftngp08...
Mark Waser
It's good to know that I'm not going crazy or making some obvious
mistake . . . .
I guess the conclusion is to stick with the fields (which are apparently
handled correctly) and avoid the properties (which the compiler apparently
messes up) OR, of course, switch to C#.
Can you or should I report this as a bug to Microsoft?
Also, I'm afraid that I don't know what you mean by the V1.1 beta bits
or what you mean by trying the VB code against them (or even why you might
not be at liberty to give me even a general recap of the results - -
especially if there is some way I can get the same results - - if I weren't
totally lost again . . . . :-)
Mark
"Christoph Schittko" <ChristophDo...@austin.rr.com> wrote in message
news:uIyonjUcCHA.2220@tkmsftngp10...
Christoph Schittko
serialized, in your case returned, objects to C#. That way you can keep the
properties. C# is really not different from VB.Net ... once you look past
the curly braces and the semi-colons.
What I mean with V1.1 beta: There is a pre-release version of the .NET
framework for people to test drive and report bugs before it is released to
production use. According to the roadmap V1.1 should be release before the
end of the year. The public beta (preview) version is available for public
download at [1] which contains only the framework SDK. There also is a
closed beta program which includes the new version of Visual Studio .NET .
For the closed beta programs there are some restrictions on what you can
disclose to the public. I'm not sure in which rules apply here so I'd rather
not post what results I got running the VB code serializing the class when I
built it with version 1.1 of the .NET Framework. If you download the new
version of the Framework SDK, then you can make a quick example project and
see for yourself if the bug is already fixed for the next release ... in
which case we wouldn't have to bother reporting it ...
HTH,
--
Christoph Schittko
Software Architect
[1]
http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?ur
l=/MSDN-FILES/027/002/056/msdncompositedoc.xml
"Mark Waser" <mwa...@mwaser.com> wrote in message
news:#Ctc4RVcCHA.2592@tkmsftngp09...
Mark Waser
Mmph. Um . . . since you're part of the closed beta program and already
know from your test whether or not the bug has been fixed, could you please
post the bug if they haven't fixed it (since you've got a direct line to the
beta peole and they'll certainly listen to you long before they listen to
me)? For my purposes, I'll just be switching my code, but it would be nice
if Microsoft got the bug report (if it still exists) and fixed it as early
as possible for other people's sake. Thanks.
Mark
"Christoph Schittko" <ChristophDo...@austin.rr.com> wrote in message
news:ucB6uaVcCHA.2532@tkmsftngp09...
Mark Waser
oddity of not allowing the interspersing of fields and properties in
hand-written classes and/or the interspersing of simple elements (those in
the current table) and the complex elements (those in child tables) in the
datasets, you'd be doing a lot of people a HUGE favor. Thanks.
Mark
"Christoph Schittko" <ChristophDo...@austin.rr.com> wrote in message
news:ucB6uaVcCHA.2532@tkmsftngp09...
Christoph Schittko
thanks,
Christoph
"Mark Waser" <mwa...@mwaser.com> wrote in message
news:eBQMYgWcCHA.2556@tkmsftngp09...