PlainXML represents a pure Java library which includes various lightweight XML processing tools developed by Andrew Gusev to speedup and simplify development of XML processing algorithms.

Major features are:

• Generation of POJO by DTD;
• Using typed POJO for manipulation for XML documents in Java;
• XML-POJO mapping using either Java5 annotations or DTD with processing instructions;
• Ability to access and modify XML document using POJO instead of SAX or DOM;
• Custom preprocessing of XML documents using expression language;
• Support of "binary" XML format;
• RMI friendly XML marshalling;
• Export JavaBeans tree to JSON;

Major principles, which are supported and implemented by library, are the corresponding:

• Having one common base class for all POJO which represent XML elements - this allows to implement various algorithms of XML processing using uniform approach as well as reduce length of code in inherited concrete classes (since most of basic methods are implemented in the basic class);
• Don't write it, generate it! - if some code may be generated, it is no use writing it manually. During library development it was assumed that most of POJO which are related to specific XML elements will be generated on basis of DTD (probably with some additional processing instructions);
• Integration of metadata into concrete XML POJO - if they are not created manually, but generated according to model, an appropriate definitions of attribute names, element name (and metatype) as well ad DTD definition is automatically added to class. Such approach allows to have self-contained inherited class, allows to hide actual names of elements and attributes from processing code as well as allows to simplify later modification of XML model. Each concrete XML POJO also includes "meta-type" property which is unique and specific for particular XML element. Such meta-type allows distinguishing instances of concrete POJOs and reducing using of instanceof statement as well as class casting. In addition, such approach allows to create more universal algorithms of XML transformations;
• Usage of JavaBeans notation - allows to hide details of XML names from algorithms which perform transformations of XML as well as makes it posible to provide transparent Java-natural style of business logic implementations. Use of Java5 generics and java.lang.Iterable allows to significantly reduce the calling code;
• Using typed setXXX() and getXXX() methods - allows to handle XML attributes and elements on higher level of abstraction as well as allows to handle incorrect values of attributes using declarative approach;
• Incorrect data - yet correct functioning. While working with XML, the library supports working with not completely correct data - based on appropriate policy, unknown XML element may be either ignored or handled as generic XML element. Unknown attribute may be also be ignored or treated as generic attribute. Unknown value of attribute may be corrected during accessing it from method which implements particular business logic;
• Special class is used for support of Java serialization/de-serialization and only that class is serializable (while particular XML POJOs are not). Such approach allows to separate details of "persistence" level from "business logic" level and eliminates problems with different versions of serialized objects. In general, during Java serialization/de-serialization it does not matter if object is stored in plain text-based XML or in some compact binary format;
• Child element does not contain reference to parent element- such a limitation allows to simplify significantly the internal implementation of basic methods and assumes that most searches of within XML tree are performed from root to leaves. If such a approach is not applicable because of some restrictions or requirements, it's possible to use XMLTreeWalker class which provides information about all parents of particular element;
• "Everything that one can say may be said simply" - during implementation of basic set of methods simplicity and transparency of their later use was one of the primary goals. In most cases, standard approaches which require for their implementation heavyweight data structures as well as complex algorithms of internal optimization were replaced by their lightweight analogs (like method isMatch());
• There is no silver bullet - it is real life and there are many different forms and approaches which shine in particular application and are completely unacceptable for another one. That is why library supports several "concurrent" paradigms of usage. Within every of them, the user of library may tune library functionality with minimal efforts. For example, if there is some hierarchy of POJO and POJO is required to be XML-enabled, it is enough to add appropriate Java5 annotations to do this.