[Mono-devel-list] xml serialization framework

Wed Apr 23 01:09:38 EDT 2003

 hi,

Atsushi’s xml-feature.txt looks like a good summary of the state of System.Xml. I like it.

Concerning the use of libxml. Are we hoping that mono will plug into it? I would favour not, but performance may be better with the native code doing the work. The parsing mechanism is fairly different I think, and may not plug into XmlReader's stream reader logic well.

Note: the serializer only poorly supports the various Xml*Attribute modifiers as well as XmlAttributeOverrides. These provide "easy" custom serialization. 

Bellow are some thoughts on the implementation of Xml.Serialization. I’m sharing this because I’d like some feedback and sanity checks on where this is going; it also ensures that we’re all on the same page. Ideas and suggestions are welcome. Most of this is conjecture, the inner workings of the xml serialization are mysterious, and I’m not planning to decompile any proprietary code.

XmlSerialization/XmlSerializationWriter (confirmed through the code generated by the serializer, thanks to Miguel for the hint, and Atsushi for the code):

XmlSerializer must have an "internal" derived class of XmlSerializationWriter (which is abstract, and so not usable on its own - the XmlSerializer implementation prob just implements InitCallbacks to do nothing). Some of XmlSerializer's functionalify will be re-deligated to XmlSerializationWriter. Such functionality includes namespace prefixing for writing XmlQualifiedNames (QNames to the XML people) and writing typed and untyped primitive types as well XmlNodes.

Custom serializers derived from XmlSerialization are probably generated to implement a brute-force version of what the base serializer does with reflection (in other words: enumerates all the members individually as well as suppress member serialization when set to default values). The derived serializer may fall back to the base class to serialize "object" members (and corresponding anyType elements). This means that the generic serialization code and XmlSerializer generator are probably pluggable as components onto the same serializer-reflection framework. Should generators use CodeDom or Reflection.Emit to do the work? (CodeDom would require post-compiling and is still far from complete. I’m hoping to spend some time on this later as it will be useful for Web-Service proxy generation with WSDL.exe) MS’s generated code is messy and uses some very cryptic naming conventions. Compatibility may require us to map these conventions, but I hate to see things written so poorly.

The magic of callbacks: search me. Actually, these look like ways to register special handling of reading/writing. Because none of the Callback delegates have any writer/reader arguments, I would guess that these delegates must be implemented in derived implementations of XmlSerializationReader/Writer (and consequently registered in their implementation of InitCallbacks), so that the callback has access to the readers/writers, as well as any other serialization info such as overrides.

-         XmlSerializationWriteCallback:custom deserialization of the object which is its argument, XmlSerializationWriter uses a type to callback mapping (see XmlSerializationWriter.AddWriteCallback)

-         The Collection callback probably handles wrapping/unwrapping element depths with collections and arrays which don’t always have a containing element.

Tests on this are in the works.

Error reporting: It looks like XmlSerializationWriter is meant to construct the error messages generated when serialization fails. See XmlSerializationWriter. CreateUnknownAnyElementException (among others). XmlSerialization should delegate error message generation here as well as writing.

XmlReflectionImporter: this looks like the main element name/ns generator for XmlSerialization.ctr’s Type argument (note that default namespace and XmlAttributeOverrides should also be fed in here). This class also allows for the requesting of member serialization info, and so an instance of this class should persist for the lifetime of the serializer so as to facilitate the naming of members contained throughout the class structure (this would require that fetching member info also lookup the appropriate override info… what to do when serializing and Xml Attribute though… they don’t use the same XmlAttributes info?).

XmlReflectionImporter related: this class’ methods return several structures meant only for use within the serializer. XmlTypeMapping, XmlMembersMapping and indirectly XmlMemberMapping. The first sets the tone for the other two. Its properties are all read-only. Its constructor is internal (this means there will be no test suits to test these classes directly… and consequently map out MS’ behaviour). The later two also have read-only properties, and thus should have internal constructors that allow for their complete initialization. Presently their constructors are internal, but don’t do any initialization. These classes represent the naming info of the reflection importer.

TypeTranslator: this is the core type to xml name mapper. It does not take into consideration attribute overrides or member status, and is used by XmlReflectionImporter to fetch the default name for all types. The results are returned as TypeData objects.

Xml*Attributes/Soap*Attributes: attributes to markup classes for serialization. Not much for us to do here. The real work will be in getting XmlSerializer to use them properly.

XmlSchemaImporter/Exporter, XmlCodeExporter, SoapSchemaImporter/Exporter/Member, are all loose cannons so far. Haven’t delved into these, and am open to insights that people have to offer.

Well that’s all for now. Hope it helps, more should follow.

Regards, and thanks for the help so far,

erik

---------------------------------
Post your free ad now! Yahoo! Canada Personals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20030423/a041ae4f/attachment.html 