Re: A good argument for XML

>Does every participant gets identical package or not? As they
>participate in the same event I assume they do.

I would say 70 to 80 percent is identical because their personal data is prefilled in many places.

>I still fail to understand why the output is hierarchical. One way to
>improve communication is to express your example formally in SQL. About
>1 page, no more, although you can indicate places where the scale goes
>up.
>
>Then, we have a discussion.

I hear the part about writing formal SQL. Let me try this first. The Event is root level, Participant is second level, Faculty would be third level. I personally don't care much for XML as a "Brand" but I'll use it to illustrate.

<event>

   <location>Singapur</location>
   <start day>1-Jan-2006</startday>
   <participant>
      <FirstName>Peter</name>
      <LastName>Gonzales</name>
      <agenda>
         <item>
            <day>1</day>
            <subject>Why XML is bad</subject>
         </item>
         <item
            <day>2</day>
            <subject>Is Bill Gates related to Bush? </subject>
         </item>
      </agenda>
      </ce_forms>
         <form> .....  </form>
         <form> .....  </form>
      <ce form>
   <participant>
            ...

Ok this is just a portion of how the XML could look like. This looks a lot more like the final content. Versus a very big spreadsheet. That is my whole argument. I don't think anybody intends that reports should be big spreadsheets. But even from the report design perspective having the ability of using only one query to produce the data to fill out the entire report seems more manageable. It's like a table of contents.

That last sentence just made me think of another example. This report is hierarchical in the same sense many books are

book

   introduction

      paragraph
         sentence
   chapter 1
      section 1.1
      section 1.2
      exercises
      bibliography

My contention is that even when a simple master-detail report could be done from tabular or hierarchical input. That it might be better to design the data transformation on the query rather than in the report formation. There are gray areas here. I would like to hear from somebody that might have tried it and see how did his/her experience turned out. And I will admit until I test this idea I am not completely sure how it will turn out. I am just frustated with the continuos strugle between sparse code on the report writer and sql functions or views. And the bottle neck looks like it is the tabular output.

Arturo Hernandez Received on Fri Jul 15 2005 - 20:30:39 CEST