[Mono-dev] [PATCH] System.Xml.Serialization (compatibility) fixes

Gert Driesen gert.driesen at telenet.be
Sun Jan 22 11:57:41 EST 2006


I've attached a patch which fixes quite some (compatibility) issues in

I know this is quite a large patch. If you want me to split the patch up
into small bug reports (with small patches), just let me know.


* XmlSerializer.cs: Added constant for WSDL Types namespace.

* TypeData.cs: Added ItemTypeName property, necessary for byte[] on
2.0 profile. Added IsFlags property for enums. On 2.0 profile, use
ListItemTypeData.ItemTypeName for TypeName property if SchemeType
is Array, and type is an array. For types implementing ICollection,
verify if there's an Add method for the ListItemType. For types
implementing IEnumerable, use the property type of the Current
property of the enumerator as ListItemType, and verify if there's
a corresponding Add method, or an Add method taking an object as

* XmlSchemaExporter.cs: In ImportTypeMapping, report failure for
type with SchemeType XmlNode and with zero-length element name. For
encoded SOAP schema, also support exporting enum and array types.
To match MS.NET, never mark a type member nillable on 1.0 profile for
encoded SOAP schema. If exported type is non-xsd primitive type
(meaning char or guid), also import its namespace. Export bit field
enums as list of simple types. When exporting array schema, also
import SOAP encoding namespace if we're generating encoded SOAP
schema. Mark attribute required if it has no default value, is not
optional value type and is not a value type. Introduced
XmlSchemaObjectContainer class that is used to achieve the same
order of elements than MS.NET.

* XmlReflectionImporter.cs: Added and used (wherever possible) Import
methods that take TypeData (instead of Type), as we need this when
a given type can be representing multiple XSD types (eg. DateTime
can represent dateTime, date, ...). If SchemaType is XmlNode, set
element name to string.Empty, and namespace to null. For non-XSD
primitive types, use http://microsoft.com/wsdl/types as namespace.
In 2.0 profile, QName is nillable.

* SoapReflectionImporter.cs: Added and used (wherever possible) Import
methods that take TypeData (instead of Type), as we need this when
a given type can be representing multiple XSD types (eg. DateTime
can represent dateTime, date, ...). Do not report failure when
importing a value type. Do not register base type for types deriving
from ValueType. Report failure when attempting to import value type
list, and type is not a primitive type (meaning guid), and is not
an enum. Use http://microsoft.com/wsdl/types as namespace non-XSD
primitive types (meaning char and guid).

* XmlSchemaImporter.cs: Added ReflectType overload that takes TypeData
instead, as we need this to differentiate between different DateTime
based XSD primitive types (such as dateTime, date, ...).

* TypeTranslator.cs: Use ArrayOfByte ListItemTypeName for byte[] on
2.0 profile. Do not register TimeSpan as XSD primitive type, to match
MS.NET. duration XSD type is string backed, not TimeSpan.


One thing to note about the patch is that there's some conditional code
in the unit tests (using an "MS" directive). This is necessary to get
all unit tests to pass on both Mono (1.0 and 2.0) and MS.NET (1.x and
2.0) until bug #77117 is fixed.

I don't think its a good idea to commit these unit tests as is, but I
wanted to get feedback on what to do. Either we:

1. Duplicate all related unit tests, which means we'll have a version
that passes on Mono (until bug #77117 is fixed) and one that passed on
MS.NET. This allows us to track regressions in Mono, and catch changes
in future versions of MS.NET.

2. Remove all conditional code and mark the tests "NotDotNet". Once bug
#77117 is fixed, we can modify the tests accordingly and remove the
NotDotNet category.

3. ???

What do you think ?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmlser.diff
Type: text/x-patch
Size: 266912 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060122/0ddd1f64/attachment.bin 

More information about the Mono-devel-list mailing list