The right way to understand XML is not as a technology but as a technique. The constellation of XML standards is just a toolset, and not every XML standard is useful. The important thing is to to be able to recognize strong and weak uses of XML.
There is one overarching "why" behind XML technology: it enables an important, obvious technique, but one that is too often ignored. This "XML technique" provides an excellent framework for deciding how and when - or when not - to apply any specific XML technology.
Continue reading "XML Best Practices"
Several engineers are building a complicated software system together, and naturally, they are trying to figure out how to divide the work up. There are two different strategies that they can take.
In the abstract, you can approach any architectural division either way, although in practice usually one way fits better than the other. How can you tell which one is right? Let's take a look at an example.
Continue reading "Encapsulation or Representation"
I am a contributor to a new Apache-project-in-incubation called XMLBeans, a powerful new Java/XML binding tool.
Although folks are starting to use it, and there is some reasonable documentaion, nobody has explained the architecture of the tool, or explained the "why" behind the "how."
This is the first in a series of entries that will discuss the problem of Java/XML binding and the explain the thinking behind the XMLBeans approach to solving it.
Continue reading "The Design of XMLBeans (Part 1)"
This article continues my series on the architecture of XMLBeans, an open-source Java/XML binding tool.
In the first article, we introduced two basic architectural principles: type correspondence and node correspondence, and we looked at some of the ramifications of type correspondence. In this article, we begin to examine node correspondence.
Continue reading "The Design of XMLBeans (Part 2)"
Your software should be compatible with its previous versions.
Was that a cold chill that just ran down your spine?
The words "compatibility with old versions" strikes fear into the hearts of programmers. The story usually begins like this. After months of hard work, a team of programmers builds the next greatest gadget, complete with the latest gizmos and conformant to the newest buzzwords. And then management blesses the shiny contraption as a successful human achievement, as close to perfection as could be possible. And they hurry it - just in the nick of time - into the hands of carefully groomed customers in exchange for a bite of their wallets. Throw a big party, break out the champange, hurrah.
Continue reading "No Theory of Compatibility?"
Since the release of JSR 31, folks in the Java community have been using Sun's JAXB reference implementation, yet they occassionally stumble on problems and shortcomings.
The JAXB spec attempts to fill an important niche in the Java world: it provides binding between XML and Java. However, in many ways, JAXB 1 fails to live up to its charter, which is to provide a standard, reliable, and usable binding of XML Schema to Java. The structure of the JAXB specification prohibits full implemetation of the W3C XML Schema standard, and it also fails to define rules that reliably provide robust and easy-to-use Java bindings. I am serving on the JAXB 2 expert group to try to help remedy the situation, but my advice to people now is: avoid JAXB 1.
Continue reading "JAXB Problems"
Thanks to Dion at TheServerSide, there has been some discussion on the distinction between Encapsulation versus Representation. Some good reading has been suggested. There have also been questions.
For example, if we distinguish between encapsulation and representation, where do "Java Value Objects" lie? Value objects have an encapsulating interface, but they clearly represent just data. They seem like the Platypus, neither fish nor fowl - or maybe both.
Continue reading "Representations Stand Alone"