[xsd-users] Efficient XML Interchange Format (Exi)

[Paquette, Patrick]

Hi Boris,

> 
> Hi Patrick,
> 
> Paquette, Patrick <PaquetP at navcanada.ca> writes:
> 
> > > Actually, I think it should be pretty straightforward to 
> extend XSD 
> > > to automatically generate this code for C# classes. Maybe using
> > > partial classes or some such.
> > 
> > Perhaps an implementation that involves performing the binary
> > serialization algorithm defined above as a subclass of
> > XmlWriter/XmlReader provided by the .NET framework, that 
> way you don't
> > need to define a new language for the xsd compiler?  Don't 
> know which
> > would be easier for you.  
> 
> Because the binary format does not include meta-data (i.e., element
> and attribute names; which is one of the reasons it is faster than
> XML [binary or text]), one would still need to generate the C# code
> to perform extraction and forwarding to XmlWriter/XmlReader. But then,
> we might as well generate the extraction code directly to C# classes
> since going through XML will hurt performance.
>

Of course.  The recommendation is more along the lines of implementing a
binary serializer/deserializer that works with existing .NET constructs
to save time on implementing C# (or managed C++) bindings in
CodeSynthesis XSD.  As you're aware (but the reader might not be), a
tool for .NET (http://msdn.microsoft.com/en-us/library/x6c1kb0s.aspx)
exists to generate the code bindings to an XML schema already in the
.NET SDK, but it would be usefull if it were more interoperable with
bindings (ie binary serializers) generated from codesynthesis.  By
definition, it's already interoperable if the protocol is XML, but if we
can do binary, then it's better.

I thought the place to implement such serializers would be a subclass of
XmlWriter/Reader - but it wouldn't.

Other ideas (all dependent on using Microsofts XSD Schema Definition
Tool):
* Write a library that uses the .NET reflection API on the generated
classes to perform the CodeSynthesis serialization algorithm on them in
a generic way.
* Write some classes that utilize the System.Runtime.Serialization
namespace
(http://msdn.microsoft.com/en-us/library/system.runtime.serialization.as
px).   Like writing a class that subclasses the Formatter class to
serialize the way CodeSynthesis does, but on the classes generated by
microsofts XSD compiler (ie: only serialize properties with the
[XmlSerializable] attribute)?

These are just places to look to research a way of reusing microsofts
XSD compiler to expose CodeSythesis's binary protocols to .NET.

But, doing it this way means it opens up developers to use other binding
tools other than CodeSythesis, which probably isn't good for business ;)

The idea about SWIG exposes the custom serialization algorithm to all
languages it supports, which is better for CodeSythesis because it gets
everybody using it.

> For example, an integer in XDR is already in binary so when we do
> XDR->C# we do binary to binary conversion. 
> have binary to text (XDR->XML) and then text to binary (XML->C#)
> conversions, which seems quite wasteful to me.

I agree - going binary, then to XML, then to C# classes would be
innefficient.  The recommendation above does not require this.

> 
> Boris
> 
>