Category Archives: XBinder

New XBinder Release

We are pleased to announce the release of XBinder 2.6.1. XBinder is an XML schema code generation tool (also commonly known as an XML data-binding application) that generates C/C++, Java, and C# code to encode/decode schema instances in XML or JSON.

This is primarily a maintenance release providing bug fixes and improvements accumulated over the past year. One significant new feature that was added was support for Visual Studio 2019. For further details on fixes, please refer to the change log at

A free 30-day trial may be downloaded from the following URL:

Embedded System Support

From time to time we receive emails asking about our embedded system support: do we support this operating system or that architecture or an unusual compiler?

The usual answer to these questions is a simple yes: ASN1C and XBinder support most embedded configurations. Usually we need to know a bit about the target system configuration to make a firm answer:

  • the host and target operating systems
  • the target architecture and ABI
  • the target compiler and, if applicable, the C runtime library
  • any special build options

Our local resources are usually sufficient to make a custom build, though it’s often useful to be pointed to a freely-available compiler to make sure that no unexpected complications arise.

In this way we have built embedded libraries for all of our target languages (C/C++, C#, and Java) across multiple architectures and operating systems: Android, iOS, different versions of embedded Linux, NIOS2, QNX, Symbian, Windows CE, and vxWorks for ARM, MIPS, PowerPC, SH3/4, Xscale, and others. Some of our customers have also adapted our libraries for use with custom operating systems and compilers, too.

From the beginning we have written our runtime libraries with a “least common denominator” philosophy that minimizes the use of features that would compromise their portability across different systems, and that explains in no small part why they have found widespread adoption among diverse platforms.

We write our C runtime libraries in ANSI-compliant C, and our generated code is also ANSI compliant. As a consequence, the same code that runs on an iPhone or iPad may be used without modification on Android and Windows—and pretty much everything else in between. And while most of our sales for embedded systems target C and C++, we also produce CLDC-compliant versions of our Java runtime library alongside the same one that runs under Android using the Dalvik VM. Our C# libraries have been used in a variety of compact configurations, too.

If you’re exploring the use of ASN.1 on your embedded systems, we’d advise you to take some time to precisely describe your development and deployment platforms. We have found two significant barriers in the delivery of embedded kits:

  1. The same vocabulary is often used for different instruction set architectures—ARM is a great example of this, since it is a family of architectures. Some implementations, for example support only software floating point, while others support hardware and even vector floating point operations.
  2. Compilers vary in their adherence to standard APIs; commonly their libraries exclude POSIX or Windows sockets, for example, or standard calls for obtaining the time and date.

In each case, our build options change to provide a compatible kit.

If you’re curious about your own configuration, let us know: we’ll be glad to talk to you about it.

XBinder 2.3 Release

XBinder 2.3 is on the verge of release. New features include:

  • Support for Visual Studio 2012
  • 64-bit Windows libraries
  • Java and C# support for nillable elements (C & C++ already supported)

Log in to your account page to download XBinder 2.3, or register for an evaulation!

Java and C# Nillable Elements

The new support for nillable elements is pretty easy to work with.  A nillable element is modeled using XBNillableElem.  XBNillableElem is a wrapper class that contains a value representing an XSD type and a flag that indicates whether that value has been nilled or not. For example, you may have some XSD such as:

            <complexType name="MyComplex">
                  <xsd:element name="an_element" type="xsd:string"/>
               <xsd:attribute name="an_attribute" type="xsd:string" use="required"/>

               <!-- An element inside some complex type -->
               <xsd:element name="myComplexElem" type="MyComplex" nillable="true"/>

You will then have a field generated such as:

protected XBNillableElem<MyComplex> myComplexElem;

When creating a value for myComplexElem, you may create a nilled or not-nilled element. If you create a nilled element, you will not need to populate “an_element” (it is not present when the element is nilled), but you will need to populate “an_attribute” (it is present when the element is nilled).  Here is an example of populating myComplexElem as being nilled:

   MyComplex myComplex = new MyComplex();
   myComplex.setAn_attribute("attribute value");
   outerobj.setMyComplexElem( new XBNillableElem<MyComplex>
                                       myComplex, true /*nilled*/) );

Objective Systems CSTA Offerings

Objective Systems offers several CSTA products. This post describes the various offerings and explains how they differ from each other.

First, what is CSTA? It stands for Computer Supported Telephony Applications. It’s a set of standardized messages that can be passed back and forth between a computer and a PBX. There are three versions (called phases) of the CSTA messaging standards. You can find all kinds of information about CSTA here. In particular, the document ECMA-269 defines the messages in CSTA phase 3, the most recent phase. The document ECMA-217 defines the messages in CSTA phase 2, and the document ECMA-179 defines the messages in CSTA phase 1.

The first type of CSTA offerings are in a category that I’ll call basic API kits. These kits consist of class definitions that are created by either ASN1C or XBinder against the ASN.1 or XML schema definitions for the CSTA (and ACSE in most cases) messages. The kits also contain samples that show how some of the CSTA or ACSE messages can be encoded and decoded. Most of the kits contain at least one test client sample, which is a console-mode program that lets the user choose what operations he wants to do against the target PBX.

Most of these basic API kits are available as an evaluation kit or a purchased standalone kit. Most evaluation kits require the presence of our ASN1C product. If you don’t already have ASN1C, you can also obtain an evaluation version of that on the ASN1C product page that I provided a link to above. The evaluation kits contain mechanisms to build the ACSE and CSTA libraries that first generate the class definitions and then compile them. The evaluation period is 30 days.

A purchased standalone kit can be used without ASN1C being present. Standalone kits contain already-generated class definitions and the libraries that are built from them. The build mechanisms in a standalone kit just compile the class definitions; they don’t generate them since ASN1C may not be present.

Some already prepared evaluation versions of basic API kits can be downloaded here. It’s also possible for us to build evaluation and standalone kits for supported platforms other than those listed on the referenced page.

The second category of CSTA offerings I will call enhanced API kits. Currently there is only one product in this category: CSTADLL.

CSTADLL is for the Microsoft .Net platform. It consists of .Net class definitions generated by ASN1C against the ACSE ASN.1 specifications and the CSTA ASN.1 class definitions for all three CSTA phases, not just one phase. There are no build procedures included with CSTADLL; the class definitions are pre-packaged. The source code (in C#) for the generated class definitions is included. Besides the inclusion of class definitions for all three CSTA phases, CSTADLL includes the following additions:

  • Simplified APIs for many common operations done with CSTA messaging. For instance, to tell the target PBX to make a call, you would use a MakeCall() method instead of encoding a MakeCall message yourself.
  • Management of the TCP/IP session with the PBX.
  • A logging mechanism so the traffic between the client and the PBX can be seen.
  • Event handling that allows a user-defined callback method to be invoked when the PBX asynchronously sends an event message as part of a monitor operation.
  • A console mode sample written in C# and a GUI sample written in Visual BASIC. Source code for both samples is included. There are also several smaller C# samples.
  • Explicit support for several different common PBX models.

XBinder And Java ME, Plus An Android Update

Finding an XML data binding solution for Java ME CLDC isn’t easy.  Now, as of version 2.2, XBinder can meet your need.  We now support Java ME CLDC 1.1 with MIDP 2.0.

Using XBinder with Java ME is simple.  First, you add the -cldc option to your XBinder command line when compiling your schema.  XBinder then generates code using only the Java language features supported by Java ME (for example, it doesn’t use generics).  It also references replacement classes for some classes that are part of Java Standard Edition, but not Java Micro Edition.

Second, you use xbrt_cldc.jar instead of xbrt.jar.   Besides the normal XBinder runtime classes, this alternate JAR also contains those replacement classes that I just mentioned, which are based on open source code.

Finally, the generated code will work with an XmlPullParser.  You just  need a JAR for the XmlPull API and an implementation thereof.  These are readily available, but we conveniently provide them for you.  The provided implementation, known as kXML , is specifically targeted at constrained devices.

Update on Android Support:  Now that XBinder has direct support for the XmlPull API, which Android directly supports, we have eliminated the option and the requirement to use StAX with Android.  This reduces the footprint for XBinder-based applications on Android.