[Mono-devel-list] asorted xml implementation questions

Erik LeBel eriklebel at yahoo.ca
Wed Mar 26 11:39:18 EST 2003


Hi folks,

This message has several parts, read on…

 

XmlSerializer/XmlSerializationWriter: Judging by the argument lists of XmlSerializer’s Serialize methods, it looks like the protected method that takes the XmlSerializationWriter is probably the real serializer that the other methods should call by wrapping their stream/textwriters/xmltextwriters/etc in an XmlSerializationWriter (actually a derived class of it). XmlSerializer does not have any accessors to its writer, so the writer is protected internally. What purpose does XmlSerializationWriter actually serve? MSDN states that’s its an internal class.

 

Xml types: throughout the System.Xml code as well as some other code that supports XML serialization, there are a battery of switch and if/else if statements that convert a run-time type to an xml type. These statements all return a string representing the type, some with a namespace prefix some without. Some of these lists are incomplete. Why don’t we merge these type “conversions” into a common translator, say a Mono internal implementation and have all these independent blocks of code call it? Each implementation could provide its own namespace info, but centralizing the mapper would reduce the number of errors that could occur through the duplication of code. There are also reverse mappers for types and values... more candidates for the cause.

 

            namespace Mono.Xml

            {

                        … some class

                        public static string GetXmlTypeName(Type type)

                        {

                                    switch (type)

                                    {

                                           ...

                                    }

                                    return name;

                        }

            }

 

XmlElementAttribute order: I believe that there remains a problem with the internal nature of the Order property. If, as its comments say, it is to be used to compensate for disparities between .NET and Mono’s order of member reflection (and thus serialization order), then this property must be available outside of the System.Xml assembly. An example of this occurs when generating a WSDL from a ServiceDescription object through serialization. Element order is important in WSDLs, and Mono’s reflection order IS different from MS’s. but the internal Order option of XmlElementAttribute is not accessible to compensate. I realize that making this member public exposes an incompatibility between the .NET and Mono libraries (directly in a common class), but the alternatives are: (1) rework the reflection framework, (2) write a custom serializer, which I have done, and would like to scrap, this is a half-assed work-around on the long run. Should the Order property be made public?

 

MonoXSD: where is the MonoXSD utility refered to in bug 40238?

 

Fixes: a bit unrelated, but what is the preferred procedure for submitting fixes?

 

Best regards,

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/20030326/31902938/attachment.html 


More information about the Mono-devel-list mailing list