Re: Antw: New gda-report's DTD

["Gerhard Dieringer" <DieringG eba-haus de>]

>>> Carlos Perelló Marín <carlos@hispalinux.es> 26.07.2000  02.39 Uhr >>>
> ...
> Well, i have based this DTD in the metaphrast DTD, they are doing
> something like that, but with QT and without database access. At this
> moment the differences are minimal, you can read the metaphrast's
> documentation that explains the actual DTD very well. I hope that in a
> near future i will document our improved DTD. Look at:
> http://www.mutinybaysoftware.com/metaphrast/index.html 
> ...

I downloaded the stuff and had a look on it, but there are several things, I can't agrre with.

1.) They encode all the attributes with numerical keys, but I don't think that this is a good idea. They get a lot of attribute value tables, that have to be maintained somewhere outside the DTD. I suggest to use all the limited features of a DTD and define the legal values inside it. Then you have to maintain only one document.

example:

<!ATTLIST report
            pagesize (A4|B5|....) "A4"
            pageorientation (portrait|landscape) "portrait"
           .....

2.) I asume that the DTD describes a report template, that is to be filled with data and not an instance of a report, that already contains the data, right?
How can the coordinate values be interpreted? At least for what I call list-reports, they can't be absolut values but offsets to the start of the corresponding instance of the section?

3.) They distinguish fields and calcutaed fields where the last actually are SQL aggregates and they allow them only in the report footer. I think both points don't make too much sense because:
a) a field gets a calculated field, if the corresponding query delivers a aggrgate function
b) calculated (aggregate) fields are sometime usefully in the detail section on a report.

4.) As I wrote in my last mail, support for grouping should by added.


One last point to your modification of the DTD:
You added a child-element query to the field. This suggests, that a query should by done for every field in the report, what would be ***very*** expensive.
There should be one (or may be a few) queries, that deliver all the data needed for the report.


Gerhard