Re: A good argument for XML

> >processed to generate a report. Conceptually the reporting tool does a
> >last pass at the data and forms the output. This Pass is often used to
> >process data.
>
> And whether it is a cursor being processed or XML, it is
> processing.

I am talking of hiding calculation fields that are placed on a report just for the sake of data calculation, totaling, averaging, subreports ... I could go on and on. This is the stuff that is co-mingled with the report page forming. If anybody wanted to see how is the data processing happening in a report they NEED to navigate throught the page layout.

XML can have all those calculations done already, even if multiple passes were required to get it (thought multiple passes are rare). The only things that might need to be calculated are fields like totals per page. But the report writer can have all the fields necessary from the XML definition, and then the fields can be placed in a GUI page forming tool. Only links between the attributes of the XML vs the attributes of the report would need to be established.

These are very different kinds of processing. And there is an opportunity to distribute processes better, from a logical point of view. Not for performance or anything else. This helps undestanding of the code and therefore maintenance, coding, productivity ....

> >many people do this by querying the database from a procedural language
> >and producing and XML iteratively. But leaves programmers like me
> >hoping for a richer syntax.
>
> XML is an alleged solution looking for a problem.

I know what you are talking about, The arguments in favor of XML as I have seen them in many places are not very strong. And it also makes me wonder about the motivations behind it. In this case I am coming from a different perspective. XML is out there. And report building does seem to be a problem for which it might be well suited.

> Sincerely,
>
> Gene Wirchenko

Arturo Hernandez Received on Fri Jul 01 2005 - 04:53:17 CEST