View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007

Fall01 Final Exam Review: Issues of Serialization

Back to Final Exam Review - Fall2001


a)
1) not everything CAN be serialized. ex File Resources in an object.
2) xml is VERY picky, not all .net implementations are likely to serialize everything exactly the same way, and chances are that the serialization mechanism will have to be tweaked a good deal, especially in the beginning.
3) When you represent an Object as XML you effectively LOSE all of the objects methods and actions that it can perform on the object. You CANNOT have an object without both data and actions, other wise you just have a record, as in this case with XML.

b)
Xml schemes are what makes an xml document make any sense. They are the framework for what tags, attributes, etc you can put in an xml document and allow the data that is in the xml document to be understood. They are similiar to class definitions in the fact that they define EXACTLY the data that the xml documenent can represent, BUT they are VERY different because they only define data, NOT methods or actions.

c)
XML "instances" aren't really instances because they are only records of data, they have no actions that they can perform on thier data, and an object HAS to have both data and actions, otherwise it is't an object.

Jason Fulghum
Here's an issue that we didn't discuss, but is interesting to consider. Let's say that you output as XML instance A of class Foo, and later ADD AN INSTANCE VARIABLE TO Foo! What happens to A? Can you compile it back to an object? How do you handle that? Mark Guzdial

To the question Mark ask I would think that you have your compiler handle this but this then makes the compiler quite complex. This is also similiar to another reason in A, any idoit who feels like it can add tags to XML which might not relate to anything in any objects, or just junk, thus creating even more for your compiler to be able to weed through.
Robert Schierholz

In answer to Mark's query, this could be handled (and will have to be handled) in a couple of ways. In one way you could simply have default values that the parser would place into the new object if they were missing in the serialization. Of course add work for the programmer. Or (to leave the plane of the real) you could somehow implement an object versioning system where making changes to an object increments its version, and version conversion routines would be a part of the compiler. Of course that would be a pain in the...


Link to this Page