This is where we define the chart DOM for the new API. Not necessarily a starting point for developing the new API, but a point of many discussions around which we can easily think we are talking about the same thing until in the details we unwittingly deviate.
After looking at the JFreeReport flow engine's DOM, there is a nice pattern we can reuse in the chart DOM regarding how style are applied to chart structure. This my first quick attempt at putting out an example XML structure with a few styles defined so that we can begin to visualize the ideas that we are talking about.
I would like to work toward either a schema or a DTD that all projects can work from in tandem to realize the chart API, pillar integration and editors.
Notes from Gretchen's head:
- Keep the elements in the chart model decoupled, only referencing relationships via attributes. This buys us flexibility in the implementation and easier changes to the DOM when charts are rendered and changed dynamically (ie., drill down, chart editor design).
- Implementation: each element in the DOM is a separate Bean. Allows for building complex chart templates on the fly without data, or with a small sample dataset.
- The DOM should be structural , without dependencies on the data or presentation attributes. Not sure yet how we validate the structure against the data. Styling shouldn't need validation against the structure (ie., styles are ignored that don't relate to any defined structural element.
- Simple charts should not need to store a fully defined DOM. We can make assumptions based on what we know about categorical charts, line ccharts, pie charts, etc. (This is iffy).