The basics

 XSD vs Dingo
 Class Diagram
 NUnit Tests
 Java code

 Custom Builders




  • Supports System.Xml.Serialization
  • Generates one file per class
  • Generate concrete classes
  • Generate interface and concrete class
  • Supports jxb:extends for complexType definition
  • Plugin architecture
  • Generate source without System.Xml.Serialization support
  • Make all classes in the schema implement a given interface
  • Make all concrete classes extend a base class
  • Use your own license text
  • Generates enum class for simpleType enumerations
  • Provide a default namespace in Dingo config instead of in the schema
  • Provide your own custom source generator
  • Delegate source generation for just methods, properties and supporting methods
  • No need to recompile Dingo to generate custom code
  • Generates Java code New
  • Supports simple type substitution New
  • Better support for optional XML Schema features New
  • Import/Include remote schemas New

Although Dingo is inspired by JAXB, it is not identicle. In this first release, Dingo does not generate an ObjectFactory or the equivalent of JaxbContent. Although J2EE/J2SE uses the pattern of context lookup, it may not be applicable for .NET. The old method of looking up a service in windows used to be windows registry. At a high level both look similar, but context lookups in J2EE is dynamic, whereas windows registry is mostly static.

XSD provides several options for compiling a specific element, type or URI. Since Dingo generates one file per class, there isn't a pressing need to support those options. Once a GUI is written for Dingo, it will be easier to open a schema and compile the desired element(s) or type(s). Dingo is designed to be flexible and can be embedded within other applications. Logo
Copyright 2004 Peter Lin