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.

PRPT:Chart Dom Example

<chart xmlns="http://www.pentaho.org/namespaces/chart">
  
  <inline-stylesheet>
    axis { 			
        color: #FFF000;
        font-family: sans-serif; 		
    }
    axis label { 			
        font-weight: bold; 		
    }
    axis[type="numeric"] {
        format: "#.00%";
    }
    axis[type="datetime"] {
        format: "MM/dd  hh:mm a"; 
    }
    axis.myAxis {
        color: blue;
        font-family: "Comic Sans MS"; 
    }
  </inline-stylesheet>
  
  <plot/>
  <axis type="numeric" id="y1" position="left">
    <!-- This label represents the title for the axis -->
    <label/>
  </axis>
  
  <axis class="myAxis" type="numeric" id="y2" position="right">
    <!-- This label represents the title for the axis -->
    <label/>
  </axis>
  <axis type="datetime" id="x1" position="bottom">
    <!-- This label represents the title for the axis -->
    <label/>
  </axis>
  
  <legend/>
  
  <title/>

  <subtitles>
    <subtitle></subtitle>
    <subtitle></subtitle>
  </subtitles>

  <chart-series>
    <series id="" position="0" axis="y1"></series>
    <series id="" position="1" axis="y2"></series>
  </chart-series>
  
  <annotations>
    <annotation></annotation>
  </annotations>

  <intervals>
    <interval></interval>
  </intervals>

</chart>

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).

Notes from Dr. Evil:

Implementation: For the Top-Level chart-API stick with a more generic approach. We cannot know the numbers or types of attributes and or the elements that a certain chart is made of. In the flow-engine I kept elements very generic which then resulted in the most minimalistic interface:

interface Element 
{
   Object getAttribute(String namespace, String attributeName);
   String getNamespace();
   String getTagName();
   StyleSheet getStyle();
}

This is enough to allow a full style-resolution and to code renderers for the model. The Beans should sit on top of this interface providing programmers with getters and setters. The resulting DOM-model will be able to provide extra attributes for specific renderers without extra coding and reduces the number of conflicts caused by the limitations of the bean interfaces. The strict-typing of beans actually backfires once you try to implement the "chart-type-switching".

Structural DOM: 100% ack. Giving your example above, the DOM would act as a template for the actual chart-rendering. A DOM that has no axises defined (but requires one) will have to (a) autogenerate the axises before attempting to style them or (b) rely on the chart-normalization to auto-generate missing elements.

Actually, along with your next point "Simple charts need simple DOMs", this road leads to the common separation between the user-model and the normalized display-model. So the display-model that is passed to the renderers should be structural and complete (whatever that will mean to us ) while the user-model will alway be incomplete and possibly even full of errors. Its the normalizer's job to sort it out.