extreport.dtd

Java的Web报表库

<!--
  Report DTD for JFreeReport version 0.8.1.

  ChangeLog:
    11-Feb-2003 : Initial version
    05-Mar-2003 : Documentation
    20-May-2003 : Bug-Fix
-->

<!--

  The valid page orientations when defining a report page format.

 -->
<!ENTITY % orientations
  "portrait | landscape | reverse_landscape"
>

<!--

  The predefined page formats. This is a list of all page formats defined in
  the class com.jrefinery.report.util.PageFormatFactory.

-->
<!ENTITY % pageFormats
  "(  PAPER10X11 | PAPER10X13 | PAPER10X14 | PAPER12X11 | PAPER15X11 | PAPER7X9 | PAPER8X10 |
      PAPER9X11 | PAPER9X12 | A0 | A1 | A2 | A3 | A3_TRANSVERSE | A3_EXTRA | A3_EXTRATRANSVERSE |
      A3_ROTATED | A4 | A4_TRANSVERSE | A4_EXTRA | A4_PLUS | A4_ROTATED | A4_SMALL | A5 |
      A5_TRANSVERSE | A5_EXTRA | A5_ROTATED | A6 | A6_ROTATED | A7 | A8 | A9 | A10 |
      ANSIC | ANSID | ANSIE | ARCHA | ARCHB | ARCHC | ARCHD | ARCHE | B0 | B1 | B2 | B3 | B4 |
      B4_ROTATED | B5 | B5_TRANSVERSE | B5_ROTATED | B6 | B6_ROTATED | B7 | B8 | B9 | B10 |
      C4 | C5 | C6 | COMM10 | DL | DOUBLEPOSTCARD | DOUBLEPOSTCARD_ROTATED | ENV9 | ENV10 |
      ENV11 | ENV12 | ENV14 | ENVC0 | ENVC1 | ENVC2 | ENVC3 | ENVC4 | ENVC5 | ENVC6 | ENVC65 | ENVC7 |
      ENVCHOU3 | ENVCHOU3_ROTATED | ENVCHOU4 | ENVCHOU4_ROTATED | ENVDL | ENVINVITE | ENVISOB4 | ENVISOB5 |
      ENVISOB6 | ENVITALIAN | ENVKAKU2 | ENVKAKU2_ROTATED | ENVKAKU3 | ENVKAKU3_ROTATED | ENVMONARCH |
      ENVPERSONAL | ENVPRC1 | ENVPRC1_ROTATED | ENVPRC2 | ENVPRC2_ROTATED | ENVPRC3 | ENVPRC3_ROTATED |
      ENVPRC4 | ENVPRC4_ROTATED | ENVPRC5 | ENVPRC5_ROTATED | ENVPRC6 | ENVPRC6_ROTATED | ENVPRC7 |
      ENVPRC7_ROTATED | ENVPRC8 | ENVPRC8_ROTATED | ENVPRC9 | ENVPRC9_ROTATED | ENVPRC10 | ENVPRC10_ROTATED |
      ENVYOU4 | ENVYOU4_ROTATED | EXECUTIVE | FANFOLDUS | FANFOLDGERMAN | FANFOLDGERMANLEGAL |
      FOLIO | ISOB0 | ISOB1 | ISOB2 | ISOB3 | ISOB4 | ISOB5 | ISOB5_EXTRA | ISOB6 | ISOB7 | ISOB8 | ISOB9 |
      ISOB10 | LEDGER | LEGAL | LEGAL_EXTRA | LETTER | LETTER_TRANSVERSE | LETTER_EXTRA | LETTER_EXTRATRANSVERSE |
      LETTER_PLUS | LETTER_ROTATED | LETTER_SMALL | MONARCH | NOTE | POSTCARD | POSTCARD_ROTATED | PRC16K |
      PRC16K_ROTATED | PRC32K | PRC32K_ROTATED | PRC32K_BIG | PRC32K_BIGROTATED | QUARTO | STATEMENT | SUPERA |
      SUPERB | TABLOID | TABLOIDEXTRA )"
>

<!--

  The root element for all extended report definitions. The order of the child elements
  does matter.

 -->
<!ELEMENT report-definition (parser-config?, report-config?,
                             styles?, templates?, report-description?,
                             functions?, data-definition?)>
<!ATTLIST report-definition
  name CDATA   #IMPLIED
>

<!--

  The parser config is used to configure the available factories for the parser.
  The parser itself does not create any objects, all object creation code is outsourced
  to the factory implementations.

  The parser can handle more than one factory per type.

 -->
<!ELEMENT parser-config ((element-factory|stylekey-factory|template-factory|datadefinition-factory|object-factory|datasource-factory)*)>

<!--

  The style key factory is used to defined style keys for element style sheets.
  The style keys consist of various objects.

  There are 2 kinds of style key definitions:

  Basic Style keys:
    - contain a single string defining the value of the style key.

  Compound style keys:
    - contain a compound object, which consists of one or more other objects.

  The stylekey reference documents all known stylekeys of the base distribution.
  The reference can be generated by calling

  com.jrefinery.report.ext.ReferenceDocGenerator

 -->
<!ELEMENT stylekey-factory EMPTY>
<!ATTLIST stylekey-factory
  class      CDATA   #IMPLIED
>

<!--

  The object factory is used to create all data objects for the report definition.
  Objects are described in an

    org.jfree.xml.factory.objects.ObjectDescription

  The system knows BasicObjectDescriptions, for objects, which only have a single
  string property called "value" defined, and compound object descriptions for
  complex objects which can contain other objects.

  The basic object descriptions are mainly used for primitive data objects, like
  Float, String, Long, Int etc.

  A complete reference of all known object types and their defined properties can
  be generated by calling

  com.jrefinery.report.ext.ReferenceDocGenerator

 -->
<!ELEMENT object-factory EMPTY>
<!ATTLIST object-factory
  class      CDATA   #IMPLIED
>

<!--

  The DataSource factory is a specialized ObjectFactory for generating
  com.jrefinery.report.filter.DataSource objects.

  If the data source is a DataFilter, then an other data source can be
  stacked into it, generating a filter chain for simple data conversion.

  An alternative for using DataSources is the template factory. Templates
  define common usecases for DataSources and allow the easy configuration
  of these usecases on a single interface.

  The reference for the defined datasources is included in the Object-Factory
  reference. All DataSource object descriptions of the base distribution are
  defined in the class factory

  com.jrefinery.report.io.ext.factory.datasource.DefaultDataSourceFactory

 -->
<!ELEMENT datasource-factory EMPTY>
<!ATTLIST datasource-factory
  class      CDATA   #IMPLIED
>

<!--

  The template factory is used to generate templates. Templates are Facade
  implementations for the data source interface. A template defines a common
  usecase, f.I. a label, and provides a simple beanified interface for that
  usecase, hiding the complexity of the datasource implementation from the
  user.

  The reference for the defined templates is included in the Object-Factory
  reference. All Template object descriptions of the base distribution are
  defined in the class factory

  com.jrefinery.report.io.ext.factory.templates.TemplateClassFactory

 -->
<!ELEMENT template-factory EMPTY>
<!ATTLIST template-factory
  class      CDATA   #IMPLIED
>

<!--

  The data definition factory is not yet used and will be implemented in
  version 0.8.4, when support for subreports gets implemented.

 -->
<!ELEMENT datadefinition-factory EMPTY>
<!ATTLIST datadefinition-factory
  class      CDATA   #IMPLIED
>

<!--

  The element factory is used to define elements. Elements are defined
  by specifying their target content type, it is up to the factory to
  choose a suitable implementation.

  At the moment (0.8.1), three element types are defined:

  text/plain    - The com.jrefinery.report.TextElement
  shape/generic - The com.jrefinery.report.ShapeElement
  image/generic - The com.jrefinery.report.ImageElement

  This list is likely to grow during the next versions.

 -->
<!ELEMENT element-factory EMPTY>
<!ATTLIST element-factory
  class      CDATA   #IMPLIED
>

<!--

 The report config is used to define the ReportConfiguration properties
 and the default page format for the report.

 -->
<!ELEMENT report-config (defaultpageformat?, configuration?)>

<!--

  This defines the default page format for the report. The page format
  is used for generating and printing the report, unless the user defines
  a different page format.

  When specifying the paper size, either width and height or one of the predefined
  page formats can be defined.

  All values are defined in points (1/72 inch).
 -->
<!ELEMENT defaultpageformat EMPTY>
<!ATTLIST defaultpageformat
  width          CDATA            #IMPLIED
  height         CDATA            #IMPLIED
  pageformat     %pageFormats;    #IMPLIED
  orientation    (%orientations;) #IMPLIED
  leftmargin     CDATA            #IMPLIED
  rightmargin    CDATA            #IMPLIED
  topmargin      CDATA            #IMPLIED
  bottommargin   CDATA            #IMPLIED
>

<!--

  A list of all report properties that should be set for the report.
  The report properties are defined as strings.

 -->
<!ELEMENT configuration (property*)>

<!ELEMENT property (#PCDATA)>
<!ATTLIST property
  name           CDATA           #REQUIRED
>

<!--

  This is not yet used, and reserved for later definitions.

 -->
<!ELEMENT data-definition EMPTY>

<!--

  The styles section can be used to predefine stylesheets, which can
  be applied to the report elements and bands.

  Stylesheets can inherit values from other style sheets, the inherited
  style key definitions can be overridden by own style definitions.

  External style definition are not yet implemented.

  The order of the styles definition is important. A style sheet cannot
  be referenced, until it is defined, so parent style sheets must be defined
  before their childs.

 -->
<!ELEMENT styles (style*)>
<!ATTLIST styles
  external       CDATA           #IMPLIED
>

<!--

  Defines a single style sheet. If the stylesheet is defined in the styles
  section, defining a name is mandatory, or the style sheet cannot be referenced
  later.

  Stylesheet consist of several style keys, either basic keys or compound keys.
  The valid keys are defined by the StyleKeyFactory, the defined factories must
  contain a description for all used keys, or the report generation will fail.

 -->
<!ELEMENT style  (extends*, (basic-key|compound-key)*)>
<!ATTLIST style
  name           CDATA           #IMPLIED
>

<!--

  Defines a band defaul style sheet. This style sheet will automaticly added
  as one of the parent style sheets for all elements of the band and can be
  used to define band wide default settings.

 -->
<!ELEMENT default-style  (extends*, (basic-key|compound-key)*)>
<!ATTLIST default-style
  name           CDATA           #IMPLIED
>

<!--

  Defines a parent stylesheet for a style sheet definition. The parent is
  provides default values for the style keys and is queried, if the requested
  stylekey is not defined in the stylesheet.

  Assigning parents allows the definition of cascading style sheets and report
  wide style definitions.

  The specified parent style sheet must be defined before it can be referenced.

 -->
<!ELEMENT extends  EMPTY>
<!ATTLIST extends
  name          CDATA  #REQUIRED
>

<!--

  Defines a compound style key. Such a key contains a compound object inside,
  an object, that needs more than a single property to be configured.

  The class parameter can be used to request the creation of a specific
  subclass of the style key value object type. If you specify an incompatible
  class, you'll get ClassCastExceptions during the parsing process.

  The object factory is used to create the defined object, the specified
  class must be known to the object factories.

 -->
<!ELEMENT compound-key (basic-object|compound-object)*>
<!ATTLIST compound-key
  name           CDATA           #IMPLIED
  class          CDATA           #IMPLIED
>

<!--

  Defines a basic style key. Such a key contains a basic object inside,
  an object, that just needs a single string property to be configured.

  The class parameter can be used to request the creation of a specific
  subclass of the style key value object type. If you specify an incompatible
  class, you'll get ClassCastExceptions during the parsing process.

  The object factory is used to create the defined object, the specified
  class must be known to the object factories. If the specified object definition
  is no basic object, the object creation will also fail.

 -->
<!ELEMENT basic-key    (#PCDATA)>
<!ATTLIST basic-key
  name           CDATA           #IMPLIED