[Mono-devel-list] xml serialization framework

[Adam Chester]

Erik LeBel Wrote:
"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."

These are all 'undocumented' classes and while the functionality they
provide may well be needed, user code should not be relying on them. As
the MSDN Documentation says "This type supports the .NET Framework
infrastructure and is not intended to be used directly from your code."

I'm not sure what the mono policy is for undocumented (but public)
classes from the MS assemblies.

Regardless, I might be able to help with these at least a little. here
is what i know so far from general messing around with them:

XmlCodeExporter:
Various tools such microsoft XSD.EXE seem to use this class to create a
code representation of an XmlSchema. This class seems to translate
XmlMembersMapping or XmlTypeMapping etc into
CodeDom.CodeTypeDeclaration's (classes) to a CodeNamespace. Each schema
element has a corresponding code type declared. This code representation
is then able to be used by XmlSerializer.Serialize etc to go from Xml to
Code and back. If you can, check out the xsd.exe tool, using the
/classes option. The 'meat' of what gets generated (code classes) seems
to be performed by XmlCodeExporter. I want to write my own improved
version of this class at some point, as i'm getting fed up with writing
custom transformations on the output of this xsd.exe tool, and I'll be
in trouble if it changes in the future.

XmlSchemaImporter:
This class accepts an XmlSchemas collection on creation. It then seems
to translate from XmlSchema elements to Xml*Mapping classes. Obviously
at this point you would guess that these mapping classes are the 'middle
man' between the various representations of an xml schema (Code,
XmlSchema, etc).

As for Soap*, I don't know right now. I would have to guess they go from
whatever format soap packages arrive as (I see a SoapReflectionImporter
there), to this internal (to System.Xml) Xml*Mapping* format. So all
these Mapping classes seem to play an important role in the microsoft
implementation of xml serialization. I dont know if you need to (or
should) implement any of the undocumented ones. Also i should note, I'm
no expert on any of what i've said above but hopefully this helps.

Anyway it's late here, and who knows if anything i typed above makes
sense.

-adam

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Erik LeBel
Sent: Wednesday, 23 April 2003 3:10 PM
To: Atsushi; monodev
Subject: [Mono-devel-list] xml serialization framework


 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