"Jeff T." <yofnik@comcast.net> wrote in message news:1112196463.068274.271430@g14g2000cwa.googlegr oups.com...[color=blue]
> - Since the IXmlSerializable interface is not even documented by
> Microsoft, I wonder if this is the best approach. Perhaps I should
> rewrite my data classes so they can be automatically serialized? Will
> the tradeoffs of doing this be better in the long run?[/color]
IXmlSerializable was somewhat more documented in .NET 2.0;
so it's still there, for what that's worth. Generally you're right that its
best to avoid types that are undocumented. In this particular case,
it is being used to solve the problem of (de)serializing of XML using
XmlSerializer in whatever format an application requires so in a de
facto way there would probably be reticence to take IXmlSerializable
away in future releases. That's not to say the interface might not be
changed if the process of XML (de)serialization needed some new
step that the interface doesn't presently define, albeit unlikely.
Let's look at implementing a (de)serialization API yourself. What
methods would it have? A WriteXml method, that writes to the abstract
XmlWriter class? A ReadXml method, that reads from an abstract
XmlReader class? Well, if that's what you're going to implement anyway,
ironically it already exists on IXmlSerializable. :-)
The only difference is without marking the class as implementing the
IXmlSerializable interface, you must call these methods yourself. If
you implement IXmlSerializable, the XmlSerializer will call them for
you.
[color=blue]
> - If I were to rewrite my data classes, I assume I would need to use a
> containership model instead of an inheritance model. In other words,
> the classes would have a "HAS A" instead of an "IS A" relationship. The
> XML Serialization model does not apply well to Object Oriented
> Programming, does it?[/color]
XML is all about containment, so it's natural a serialization in XML
has a less than optimal representation for inheritance compared to
a containment model (or that inheritance must be represented by
containment).
I have seen the XML schema you've shown used to represent
inheritance in the past, though. It's not disimilar to the approach
of binary serialization.
[color=blue]
> - You mentioned that a schema would not need to be supplied.
> What if I was to supply a schema?[/color]
XmlSerializer won't use it for anything.
The .NET 2.0 Beta 1 documentation states that the XmlSchema is
needed only for generating WSDL proxies, and that it's not called
for serialization/deserialization of instances because XmlSerializer
doesn't schema-validate (which is just as well, because it'd incur
considerable overhead to do so).
[color=blue]
> I want the receivers of my data to know how to
> read it,[/color]
You can send them an XML schema document out-of-band, for
example you can implement WriteXml( ) to serialize an xsi:schema-
Location attribute. It's up to the consumer to retrieve it if they need
it.
How much it truly helps the consumers know how to read your
XML instance depends on whether the consuming application is
intelligent enough to use it to generate and execute dynamic code.
Most XML consumers aren't built that well, though, or at least
few of us are fortunate enough to have them be commonplace.
[color=blue]
> as there is no guarantee that my same data classes will be
> used on the receiving end. Can a schema be generated
> automatically or do I have to define one manually?[/color]
There's an XML Schema Inference tool here,
http://apps.gotdotnet.com/xmltools/xsdinference/
Several popular XML editors also include it as a
feature. The better implementations allow you to
specify heuristics to improve the inference.
At least, you can pass xsd.exe a file with an .xml
extension and it'll infer a schema document.
After one of these programs guesses one of the millions of
possible schemas that will validate your instance document,
it's wise to revise it manually. :-)
Derek Harmon