Like all software, Dingo has limitations. Here are the current limitations. Most of these are edge cases, or scenarios which are tricky to solve.

Naming collision

If there is a naming collision, Dingo will not handle it correctly. In the latest release, there's a new sample called dashSchema. If the complex type is renamed from <xs:complexType name="hello-worldType"> to <xs:complexType name="hello-world">, dingo will over write the element with the complexType. The solution to that is to rename the complexType to avoid collision. From a practical perspective, it's better to name the elements and types so that it is clear and concise. Using identical names is bad practice. If someone really needs the feature I'll consider implementing support.

Remote include/imports

Releases older than 1.1.3 do not support remote include/import. Starting with 1.1.3, remote schema import/include is supported.

CSL compliant Code

If the schema has attributes that differ by cases, the generated code will not be CSL compliant. The solution to this is to change the name of one of the attributes. I don't see this as a Dingo issue, since the Dingo shouldn't rename attributes. The way Dingo generates code in JAXB mode appends "Impl" suffic to the class name, but that is different than attributes. Dingo does lowercase the first letter of an attribute, when it generates code. This is done so the field does not collide with the property. If Dingo didn't lowercase the first letter for the field, the compiler would coomplain.

Custom plugins and schema that implement multiple interfaces

If a given complexType or Element implements multiple interfaces, plugins need to handle the code generation for methods properly. Say I made a complexType implement, GraphListener and java.beans.PropertyChangeListener. Generating both the get and set methods may need to be a specific order. This means only one plugin should generate the source for the methods. Since the DelegateBuilder API takes the TypeInfo object, all the necessary information is provided. For the next release, I will try to write an example illustrating this type of complex situation.

Adding custom attributes to fields and methods

Currently, there isn't a way to add custom attributes to a specific sequence of elements in a schema. After the first release, I plan to try out a couple different approaches. Because of how attributes work in C#, it isn't as simple as adding a new attribute to <element> tag. Since attributes may have a number of properties and values, the information has to be defined in the schema for Dingo to process it correctly.

Generating classes from XML

This is a feature that would be nice, but I haven't decide if I want to tackle it. I've thought about it a little, but not enough to come up with a clean and simple implementation that is flexible and extensible. My first thought was to write an XSLT to transform the XML to schema. Once the schema is generated, it would be simple to generate the classes. Another approach was to provide a GUI to load the XML and then allow users to select which elements to convert to complexType or element.

For those who need to generate a schema from XML, castor has a tool called Xml2Schema. XmlSpy can also generate schema from XML, so there are tools out there for generating schema from XML. Generating the schema from XML isn't hard. It just takes time. JAXB mode and inheritance

Dingo converts elements defined by a top level complexType is it generates 4 classes: testType, test, testTypeImpl, testImpl. The two classes with "Impl" suffix are the concrete classes. The other two are interfaces. Dingo creates the full interface from the complexType. For the interface defining the element, it simply has it extend the complexType interface.

• testType - complexType producing a C# interface
• test - element using testType as the type. The interface simple extends testType interface
• testTypeImpl - the concrete class implementing testType interface
• testImpl - the concrete class extending testTypeImpl and implementing test interface

JAXBContext and lookups

JAXB uses context lookup, but Dingo currently does not. I haven't decided if this is a good idea or not. The good thing about context lookup is consumers can look up a different ObjectFactory. In the first release of JAXB, there was a bug with context lookup when the properties file is packaged inside the jar. I'm not sure there is an elegant solution that is the same as Java. Since assemblies do not contain text properties files, I am exploring which approach would be better. The nice thing about jar files is it makes it easier to package the classes and all required files into one package. In .NET, assemblies do not text files. This is understandable, since dll's have to be backward compatible. I'm hoping .NET 3.0 will consider a similar approach to jar files. I believe .NET 2.0 improves versioning of assemblies, but it still does not include text files within the assembly. Jar files sometimes can be a pain. The most common case is when a user wants to change a setting in the properties files. There are a couple of ways of handling properties files, but I'm not going to bother getting into this topic. Google for resources on this topic.

Generating classes from Database tables

I plan to eventually write a tool to do this, but for the first release, Dingo does not provide one. The default VS.NET schema support for mapping database tables to objects is rather simple and inadequate for complex scenarios. Since I don't work on simple applications, I've given up using VS.NET's schema tool altogether. For Dingo 2.0, I plan on writing a GUI for editing, viewing, importing and exporting schema. There's quite a few things I would like to add to Dingo, but I don't have much free time. The little free time I have, I try to be as productive as possible.

Updated 9-30-2004 Peter