how to ingrate xml support in lire

[Jan Stap]

My previous mail is answered: nice!

Jan

----- Original Message -----
From: "Egon Willighagen" <egonw at subdimension.com>
To: "Joost van Baal" <joostvb at logreport.org>; <development at logreport.org>
Sent: Friday, March 16, 2001 20:12
Subject: Re: how to ingrate xml support in lire


> Op donderdag 15 maart 2001 20:47, schreef Joost van Baal:
> > LOGFILE -> service2dlf -> DLF FILE ->
> >          various small report scripts -> RAW REPORT
> >
> > RAW REPORT -> querycalc-tidy -> FORMATTED ASCII REPORT
> >
> > I believe it would be wisest to get rid of the raw report format.
> > This might better be replaced by an xml file, since this gives
> > us the possibility to support richer data structures.  We'll gain
> > flexibility by doing this.
>
> I agree. But by choosing XML as format, you also choose the tools.
> And this *will* raise the footprint.
>
> Unless...
>
> We find good means of identifying the XML tools already available on the
> system when Lire is installed. It requires GCC to be installed, why not
> require XML tools as well....
>
> A second option is that though we use XML as in internal format, the user
> is *not* required XML tools, and a small script is used to convert the XML
> report into a ASCII report (this script will be written).
>
> However, more complex functionality we want to add later, like merging new
> reports to older report to get a picture of the information flow in time,
are
> getting increasingly more diffecult if no XML tools are used...
>
> Thus, the in between solution is, if the user wants a small footprint, it
can
> do limited things. If he (or she) needs to do more interesting things,
> time-dependant report, clustering of data, he will need XML tools.
>
> (my opinion :)
>
> > If we choose to do this, all small report scripts (
> >   report_*
> > ) need to be changed. They should generate small xml files,
> > instead of the current raw report snippets.
>
> I propose to start do this, just after this months release (this weekend?)
>
> > I don't think we should enforce the use of big xml parsers.
>
> XML parsers or often not large... as small as 34 kB... (Java's Aelfred).
> Xalan and Xerces are strange exceptions... but offer much more than
> just XSLT processing and XML parsing respectively...
>
> > If people desire to stick with the simple ascii reports, they should be
> > able to do so, without using big xml parsers.
>
> This is the solution above... (which Joost and I discussed yesterday)...
>
> > I don't think a solaris sysadmin would like to install lire, if she
> > needed to install xalan or something similar next to it, in order to be
> > able to use it.
>
> 1) As said above, we might detect XML tools available
> 2) XML support will grow... so the change of finding tools as well
> 3) Lire might install Xerces/Xalan-C itself, if no tools available
> 4) Or... just ascii reports.
>
> > We could write a parser for our own small xml files, which does
> > _just_ enough to generate an ascii report. (I have no clue about how
> > difficult this is.)
>
> Me neither. I think i have it up and running within a week, but it will
> not be flexible... and a fear breaks now and then... but that's all
internal
> stuff we/I know about...
>
> > A less nice solution would be to keep the
> > current raw reports, and convert these to xml (I believe we have
> > something like this in place now.)
>
> Not just 'less nice', but if we do this we would loose the advantage of
XML
> properties...
>
> > When we choose to do this, we
> > could keep our current querycalc-tidy.  However, the system will
> > not gain in flexibility this way.
>
> Indeed :)
>
> > Is my story clear?  Any comments?
>
> Hereby...
>
> Egon
>
> --
> To UNSUBSCRIBE, email to development-request at logreport.org with a subject
of
> "unsubscribe". Trouble? Send an email with subject "help" to
> development-request at logreport.org
>


-- 
To UNSUBSCRIBE, email to development-request at logreport.org with a subject of 
"unsubscribe". Trouble? Send an email with subject "help" to 
development-request at logreport.org