Best way to serialize unknown data

[Michel]

Hi there,

What is the best way to serialize unknown data?
I have a class that contains a list of parameter objects.
The parameter has a value which can be a simple value of a complex class,
e.g.

class param {
object value;
}

When serializing, I must always have the same name for the value element.

I've looked at 2 approaches:
1) Value is of type object. XmlSerializer MUST know the object's type.
2) Value is of type XmlElement. XmlSerializer doesn't care about content.

Which is better?
1 is easy but has a limitation, 2 is more work.

In addition, the receiver of the xml does not understand type definitions
(it will generate an error) so I cannot have these in my xml.
Does this limit my possibilities to XmlElement IF I want to Deserialize the
same xml?

Any help appreciated,
Michel

[Christoph Schittko [MVP]]

Michel,

You could inspect the type of the value property and dynamically create an
XmlSerializer instances for every type. You can declare the type and the
element name dynamically using the XmlSerializer constructor that takes an
XmlAttributeOve rrides parameter.

However, constructing an XmlSerializer is a pretty expensive operation, so
this approach carries a lot of overhead if the types are completely random
and don't repeat. I am assuming though, that it's not completely random,
since you're application can only know so many types. Is there a reason you
can't just add A LOT of XmlElement attributes to the class, either at
compile time or using the XmlAttributeOve rrides parameter?

If you're really working with completely arbitratry XML then typing the
property as XmlElement is the best way to go.
--
HTH
Christoph Schittko [MVP, XmlInsider]
Software Architect, .NET Mentor

"Michel" <ms*@virtualsci ences.nl> wrote in message
news:c0******** **@reader10.wxs .nl...

Hi there,

What is the best way to serialize unknown data?
I have a class that contains a list of parameter objects.
The parameter has a value which can be a simple value of a complex class,
e.g.

class param {
object value;
}

When serializing, I must always have the same name for the value element.

I've looked at 2 approaches:
1) Value is of type object. XmlSerializer MUST know the object's type.
2) Value is of type XmlElement. XmlSerializer doesn't care about content.

Which is better?
1 is easy but has a limitation, 2 is more work.

In addition, the receiver of the xml does not understand type definitions
(it will generate an error) so I cannot have these in my xml.
Does this limit my possibilities to XmlElement IF I want to Deserialize the same xml?

Any help appreciated,
Michel

[Michel]

Hi Christoph,

Thanks for your answer.

As you note, there is a limit to the amount of classes I use, so I can tell
XmlSerializer, either run- or compiletime. That is what I do now (I examine
the classes used before creating the XmlSerializer and register them in
XmlSerializer's constructor). Note I use the "object solution" and serialize
only one object (the one that contains all the others).
I think I'll use your argument that XmlSerializer is expensive and stick to
my current solution.
I haven't looked at XmlAttributeOve rrides but I will.

Thanks again,
Michel

"Christoph Schittko [MVP]" <ch************ ********@austin .rr.com> wrote in
message news:eq******** ******@TK2MSFTN GP11.phx.gbl...

Michel,

You could inspect the type of the value property and dynamically create an
XmlSerializer instances for every type. You can declare the type and the
element name dynamically using the XmlSerializer constructor that takes an
XmlAttributeOve rrides parameter.

However, constructing an XmlSerializer is a pretty expensive operation, so
this approach carries a lot of overhead if the types are completely random
and don't repeat. I am assuming though, that it's not completely random,
since you're application can only know so many types. Is there a reason you can't just add A LOT of XmlElement attributes to the class, either at
compile time or using the XmlAttributeOve rrides parameter?

If you're really working with completely arbitratry XML then typing the
property as XmlElement is the best way to go.
--
HTH
Christoph Schittko [MVP, XmlInsider]
Software Architect, .NET Mentor

"Michel" <ms*@virtualsci ences.nl> wrote in message
news:c0******** **@reader10.wxs .nl...

Hi there,

What is the best way to serialize unknown data?
I have a class that contains a list of parameter objects.
The parameter has a value which can be a simple value of a complex class, e.g.

class param {
object value;
}

When serializing, I must always have the same name for the value element.
I've looked at 2 approaches:
1) Value is of type object. XmlSerializer MUST know the object's type.
2) Value is of type XmlElement. XmlSerializer doesn't care about content.
Which is better?
1 is easy but has a limitation, 2 is more work.

In addition, the receiver of the xml does not understand type definitions (it will generate an error) so I cannot have these in my xml.
Does this limit my possibilities to XmlElement IF I want to Deserialize

the

same xml?

Any help appreciated,
Michel

[Christoph Schittko [MVP]]

Michel,

Note that only the first instantiation of the XmlSerializer is very
expensive. Subsequent ones carry less overhead and you might even be able to
avoid that altogether if you can determine the set of attributes to apply in
the source code or the XmlAttributeOve rrides and keep the XmlSerializer
instance around for the lifetime of your app.

--
HTH
Christoph Schittko [MVP, XmlInsider]
Software Architect, .NET Mentor

"Michel" <ms*@virtualsci ences.nl> wrote in message
news:c0******** **@reader08.wxs .nl...

Hi Christoph,

Thanks for your answer.

As you note, there is a limit to the amount of classes I use, so I can tell XmlSerializer, either run- or compiletime. That is what I do now (I examine the classes used before creating the XmlSerializer and register them in
XmlSerializer's constructor). Note I use the "object solution" and serialize only one object (the one that contains all the others).
I think I'll use your argument that XmlSerializer is expensive and stick to my current solution.
I haven't looked at XmlAttributeOve rrides but I will.

Thanks again,
Michel

"Christoph Schittko [MVP]" <ch************ ********@austin .rr.com> wrote in
message news:eq******** ******@TK2MSFTN GP11.phx.gbl...

Michel,

You could inspect the type of the value property and dynamically create an

XmlSerializer instances for every type. You can declare the type and the
element name dynamically using the XmlSerializer constructor that takes an XmlAttributeOve rrides parameter.

However, constructing an XmlSerializer is a pretty expensive operation, so this approach carries a lot of overhead if the types are completely random and don't repeat. I am assuming though, that it's not completely random,
since you're application can only know so many types. Is there a reason

you

can't just add A LOT of XmlElement attributes to the class, either at
compile time or using the XmlAttributeOve rrides parameter?

If you're really working with completely arbitratry XML then typing the
property as XmlElement is the best way to go.
--
HTH
Christoph Schittko [MVP, XmlInsider]
Software Architect, .NET Mentor

"Michel" <ms*@virtualsci ences.nl> wrote in message
news:c0******** **@reader10.wxs .nl...

Hi there,

What is the best way to serialize unknown data?
I have a class that contains a list of parameter objects.
The parameter has a value which can be a simple value of a complex class, e.g.

class param {
object value;
}

When serializing, I must always have the same name for the value element.
I've looked at 2 approaches:
1) Value is of type object. XmlSerializer MUST know the object's type.
2) Value is of type XmlElement. XmlSerializer doesn't care about content.
Which is better?
1 is easy but has a limitation, 2 is more work.

In addition, the receiver of the xml does not understand type definitions (it will generate an error) so I cannot have these in my xml.
Does this limit my possibilities to XmlElement IF I want to

Deserialize the

same xml?

Any help appreciated,
Michel

[Michel]

Hi Christoph,

Thanks for pointing this out.
The only question I have about this is, the client of my COM object is an
asp site.
My asp knowledge is pretty slim, but my guess is different requests live in
different threads.
So, if I have a shared XmlSerializer object, do I need to make the calls to
it thread safe?

Thanks,
Michel

"Christoph Schittko [MVP]" <ch************ ********@austin .rr.com> wrote in
message news:us******** ******@TK2MSFTN GP12.phx.gbl...

Michel,

Note that only the first instantiation of the XmlSerializer is very
expensive. Subsequent ones carry less overhead and you might even be able to avoid that altogether if you can determine the set of attributes to apply in the source code or the XmlAttributeOve rrides and keep the XmlSerializer
instance around for the lifetime of your app.

--
HTH
Christoph Schittko [MVP, XmlInsider]
Software Architect, .NET Mentor

"Michel" <ms*@virtualsci ences.nl> wrote in message
news:c0******** **@reader08.wxs .nl...

Hi Christoph,

Thanks for your answer.

As you note, there is a limit to the amount of classes I use, so I can tell

XmlSerializer, either run- or compiletime. That is what I do now (I

examine

the classes used before creating the XmlSerializer and register them in
XmlSerializer's constructor). Note I use the "object solution" and

serialize

only one object (the one that contains all the others).
I think I'll use your argument that XmlSerializer is expensive and stick

to

my current solution.
I haven't looked at XmlAttributeOve rrides but I will.

Thanks again,
Michel

"Christoph Schittko [MVP]" <ch************ ********@austin .rr.com> wrote in

message news:eq******** ******@TK2MSFTN GP11.phx.gbl...

Michel,

You could inspect the type of the value property and dynamically create an XmlSerializer instances for every type. You can declare the type and

the element name dynamically using the XmlSerializer constructor that takes

an XmlAttributeOve rrides parameter.

However, constructing an XmlSerializer is a pretty expensive

operation,

so this approach carries a lot of overhead if the types are completely random and don't repeat. I am assuming though, that it's not completely

random, since you're application can only know so many types. Is there a reason

you

can't just add A LOT of XmlElement attributes to the class, either at
compile time or using the XmlAttributeOve rrides parameter?

If you're really working with completely arbitratry XML then typing

the property as XmlElement is the best way to go.
--
HTH
Christoph Schittko [MVP, XmlInsider]
Software Architect, .NET Mentor

"Michel" <ms*@virtualsci ences.nl> wrote in message
news:c0******** **@reader10.wxs .nl...
> Hi there,
>
> What is the best way to serialize unknown data?
> I have a class that contains a list of parameter objects.
> The parameter has a value which can be a simple value of a complex

class,

> e.g.
>
> class param {
> object value;
> }
>
> When serializing, I must always have the same name for the value

element.

>
> I've looked at 2 approaches:
> 1) Value is of type object. XmlSerializer MUST know the object's type. > 2) Value is of type XmlElement. XmlSerializer doesn't care about

content.

>
> Which is better?
> 1 is easy but has a limitation, 2 is more work.
>
> In addition, the receiver of the xml does not understand type

definitions

> (it will generate an error) so I cannot have these in my xml.
> Does this limit my possibilities to XmlElement IF I want to

Deserialize the
> same xml?
>
> Any help appreciated,
> Michel
>
>

[Christoph Schittko [MVP]]

No you don't need do do anything special to make the XmlSerializer thread
safe. It is thread safe as long as you don't register any non-thread-safe
event handlers.
--
HTH
Christoph Schittko [MVP, XmlInsider]
Software Architect, .NET Mentor

"Michel" <ms*@virtualsci ences.nl> wrote in message
news:c0******** **@reader08.wxs .nl...

Hi Christoph,

Thanks for pointing this out.
The only question I have about this is, the client of my COM object is an
asp site.
My asp knowledge is pretty slim, but my guess is different requests live in different threads.
So, if I have a shared XmlSerializer object, do I need to make the calls to it thread safe?

Thanks,
Michel

"Christoph Schittko [MVP]" <ch************ ********@austin .rr.com> wrote in
message news:us******** ******@TK2MSFTN GP12.phx.gbl...

Michel,

Note that only the first instantiation of the XmlSerializer is very
expensive. Subsequent ones carry less overhead and you might even be able

to

avoid that altogether if you can determine the set of attributes to apply

in

the source code or the XmlAttributeOve rrides and keep the XmlSerializer
instance around for the lifetime of your app.

--
HTH
Christoph Schittko [MVP, XmlInsider]
Software Architect, .NET Mentor

"Michel" <ms*@virtualsci ences.nl> wrote in message
news:c0******** **@reader08.wxs .nl...

Hi Christoph,

Thanks for your answer.

As you note, there is a limit to the amount of classes I use, so I can tell

XmlSerializer, either run- or compiletime. That is what I do now (I

examine

the classes used before creating the XmlSerializer and register them in XmlSerializer's constructor). Note I use the "object solution" and

serialize

only one object (the one that contains all the others).
I think I'll use your argument that XmlSerializer is expensive and stick to

my current solution.
I haven't looked at XmlAttributeOve rrides but I will.

Thanks again,
Michel

"Christoph Schittko [MVP]" <ch************ ********@austin .rr.com>

wrote in message news:eq******** ******@TK2MSFTN GP11.phx.gbl...
> Michel,
>
> You could inspect the type of the value property and dynamically create

an

> XmlSerializer instances for every type. You can declare the type and

the > element name dynamically using the XmlSerializer constructor that takes

an

> XmlAttributeOve rrides parameter.
>
> However, constructing an XmlSerializer is a pretty expensive

operation,

so

> this approach carries a lot of overhead if the types are completely

random

> and don't repeat. I am assuming though, that it's not completely

random, > since you're application can only know so many types. Is there a reason you
> can't just add A LOT of XmlElement attributes to the class, either

at > compile time or using the XmlAttributeOve rrides parameter?
>
> If you're really working with completely arbitratry XML then typing

the > property as XmlElement is the best way to go.
> --
> HTH
> Christoph Schittko [MVP, XmlInsider]
> Software Architect, .NET Mentor
>
> "Michel" <ms*@virtualsci ences.nl> wrote in message
> news:c0******** **@reader10.wxs .nl...
> > Hi there,
> >
> > What is the best way to serialize unknown data?
> > I have a class that contains a list of parameter objects.
> > The parameter has a value which can be a simple value of a complex
class,
> > e.g.
> >
> > class param {
> > object value;
> > }
> >
> > When serializing, I must always have the same name for the value
element.
> >
> > I've looked at 2 approaches:
> > 1) Value is of type object. XmlSerializer MUST know the object's type. > > 2) Value is of type XmlElement. XmlSerializer doesn't care about
content.
> >
> > Which is better?
> > 1 is easy but has a limitation, 2 is more work.
> >
> > In addition, the receiver of the xml does not understand type
definitions
> > (it will generate an error) so I cannot have these in my xml.
> > Does this limit my possibilities to XmlElement IF I want to

Deserialize

> the
> > same xml?
> >
> > Any help appreciated,
> > Michel
> >
> >
>
>