Re: Antw: New gda-report's DTD

[Carlos Perelló Marín <carlos hispalinux es>]

Gerhard Dieringer escribió:
> 
> >>> 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"
>            .....
> 

Well, as i tell you in another mail, i think that we must connect this
option with the options at /etc/paper.conf

> 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?

Yes, you are right. We must create an XML file that is the instance of a
report, which must agree the DTD structure.

> 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?

For example, we could use a flag that tell the DTD if is absolute or
relative...

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

Well, this could change, couldn't it?

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

Well, my intention was make something like the grouping that you are
talking about.

> There should be one (or may be a few) queries, that deliver all the data needed for the report.
> 
> Gerhard
> 
> _______________________________________________
> gnome-db-list mailing list
> gnome-db-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-db-list


P.S.: Excuse me, i was very busy and i couldn't reply those mails
before.

Bye
-- 
Carlos Perelló Marín
carlos@hispalinux.es
http://TorresQuevedo.hispalinux.es
http://nulies.hispalinux.es
http://www.Hispalinux.es
Valencia - España