Home » Archived » BIRT » Report Specs and XML Report Design
| Report Specs and XML Report Design [message #36] |
Thu, 16 September 2004 10:19  |
Eclipse User |
|
|
|
Looking at the proposal, I see that the XML Report Design having two
use-modes, development and run-time. I think this misses one significant
use-mode that may be useful. A significant portion of any report
development life-cycle is the specification process. It would be extremely
useful to me as a report developer if I could attach the report
specifications to the actual report design.
When we develop reports, our specification is normally done using a
combination of Excel and Word, to varying levels of detail. As the report
development progresses, the spec docs and the actual design tend to diverge,
it is hard to keep the two in sequence. In the end, the report design
becomes the specification.
If the the XML Report Design had the appropriate specification oriented
tags, it would be easier to keep the spec and the development process in
sequence. In addition, to consistancy between the spec and the design there
are three additional benefits. First, the details/text of the specification
could be of use in the report design for help to report viewers. For
example, if the relationship between two fields is expressed in the spec doc
in plain english, it would seem like this information could be used at
report view time as help to the report viewer.
Second, if the specification of the report is tied to the design, then any
information about the report (what it does, who it is designed for, the
questions that it is designed to answer) could be searchable and viewable.
For example, someone going to a repository that holds a large number of
report designs, could submit a query asking for a design that fits a
specific set of criteria. The repository could search the appropriate
specification information within the report designs it holds and provide a
list and description of all reports that fit that description.
Third, in almost all report development projects that I have participated
in, the report developer spends a significant amount of time gathering
specifications. In a perfect world a business analyst would do this, but in
the real world the report developer is the person that understands what
questions to ask. It would seem a natural fit for the report developer to
be able to extend the specifications in the same report design they are all
ready working in.
The downside is that this would require some tool for the report
specification people that allows them to view and modify the XML Report
Design, but I think that this could be accomplished as a watered-down
version of the actual report designer.
Scott Rosenbaum
|
|
|
| Re: Report Specs and XML Report Design [message #41 is a reply to message #36] |
Mon, 20 September 2004 19:47  |
| Eclipse User |
|
|
|
Scott
It is an interesting idea. In your experience, does the report spec include
only a single Excel/Word doc, or a set of such docs, or even possibly a
scanned image of the paper report?
Wenfeng
"Scott Rosenbaum" <scottr@innoventsolutions.com> wrote in message
news:cic75t$7t0$1@eclipse.org...
> Looking at the proposal, I see that the XML Report Design having two
> use-modes, development and run-time. I think this misses one significant
> use-mode that may be useful. A significant portion of any report
> development life-cycle is the specification process. It would be
extremely
> useful to me as a report developer if I could attach the report
> specifications to the actual report design.
>
> When we develop reports, our specification is normally done using a
> combination of Excel and Word, to varying levels of detail. As the report
> development progresses, the spec docs and the actual design tend to
diverge,
> it is hard to keep the two in sequence. In the end, the report design
> becomes the specification.
>
> If the the XML Report Design had the appropriate specification oriented
> tags, it would be easier to keep the spec and the development process in
> sequence. In addition, to consistancy between the spec and the design
there
> are three additional benefits. First, the details/text of the
specification
> could be of use in the report design for help to report viewers. For
> example, if the relationship between two fields is expressed in the spec
doc
> in plain english, it would seem like this information could be used at
> report view time as help to the report viewer.
>
> Second, if the specification of the report is tied to the design, then any
> information about the report (what it does, who it is designed for, the
> questions that it is designed to answer) could be searchable and viewable.
> For example, someone going to a repository that holds a large number of
> report designs, could submit a query asking for a design that fits a
> specific set of criteria. The repository could search the appropriate
> specification information within the report designs it holds and provide a
> list and description of all reports that fit that description.
>
> Third, in almost all report development projects that I have participated
> in, the report developer spends a significant amount of time gathering
> specifications. In a perfect world a business analyst would do this, but
in
> the real world the report developer is the person that understands what
> questions to ask. It would seem a natural fit for the report developer to
> be able to extend the specifications in the same report design they are
all
> ready working in.
>
> The downside is that this would require some tool for the report
> specification people that allows them to view and modify the XML Report
> Design, but I think that this could be accomplished as a watered-down
> version of the actual report designer.
>
> Scott Rosenbaum
>
>
>
>
>
>
|
|
|
| Re: Report Specs and XML Report Design [message #53 is a reply to message #41] |
Wed, 22 September 2004 18:12 |
| Eclipse User |
|
|
|
Typically each report has its own specification. That specification will
have three significant sections: a) data mapping, b) layout, c) business
rules. Generally the rules and data mapping is narrative and done in a word
doc. The layout can either be an Excel doc, a markup of a previous report,
a visio doc, or some any other visual layout.
If it were possible to combine these elements into one doc, and have closer
linking between the two, e.g. the rule governing how two columns relate is
done in the visual layout, than that would be very helpful. Also, if the
doc created by the Business Analyst was closely tied to the report template
created by the developer that would be great.
Scott
"Wenfeng" <wli@actuate.com> wrote in message
news:cinrm4$vbd$1@eclipse.org...
> Scott
> It is an interesting idea. In your experience, does the report spec
include
> only a single Excel/Word doc, or a set of such docs, or even possibly a
> scanned image of the paper report?
> Wenfeng
>
> "Scott Rosenbaum" <scottr@innoventsolutions.com> wrote in message
> news:cic75t$7t0$1@eclipse.org...
> > Looking at the proposal, I see that the XML Report Design having two
> > use-modes, development and run-time. I think this misses one
significant
> > use-mode that may be useful. A significant portion of any report
> > development life-cycle is the specification process. It would be
> extremely
> > useful to me as a report developer if I could attach the report
> > specifications to the actual report design.
> >
> > When we develop reports, our specification is normally done using a
> > combination of Excel and Word, to varying levels of detail. As the
report
> > development progresses, the spec docs and the actual design tend to
> diverge,
> > it is hard to keep the two in sequence. In the end, the report design
> > becomes the specification.
> >
> > If the the XML Report Design had the appropriate specification oriented
> > tags, it would be easier to keep the spec and the development process in
> > sequence. In addition, to consistancy between the spec and the design
> there
> > are three additional benefits. First, the details/text of the
> specification
> > could be of use in the report design for help to report viewers. For
> > example, if the relationship between two fields is expressed in the spec
> doc
> > in plain english, it would seem like this information could be used at
> > report view time as help to the report viewer.
> >
> > Second, if the specification of the report is tied to the design, then
any
> > information about the report (what it does, who it is designed for, the
> > questions that it is designed to answer) could be searchable and
viewable.
> > For example, someone going to a repository that holds a large number of
> > report designs, could submit a query asking for a design that fits a
> > specific set of criteria. The repository could search the appropriate
> > specification information within the report designs it holds and provide
a
> > list and description of all reports that fit that description.
> >
> > Third, in almost all report development projects that I have
participated
> > in, the report developer spends a significant amount of time gathering
> > specifications. In a perfect world a business analyst would do this,
but
> in
> > the real world the report developer is the person that understands what
> > questions to ask. It would seem a natural fit for the report developer
to
> > be able to extend the specifications in the same report design they are
> all
> > ready working in.
> >
> > The downside is that this would require some tool for the report
> > specification people that allows them to view and modify the XML Report
> > Design, but I think that this could be accomplished as a watered-down
> > version of the actual report designer.
> >
> > Scott Rosenbaum
> >
> >
> >
> >
> >
> >
>
>
|
|
|
Goto Forum:
Current Time: Sat May 10 00:05:58 EDT 2025
Powered by FUDForum. Page generated in 0.02648 seconds |
Home