Re: [gnome-db] Re: GRAND MASTER PLAN

[Dru <andru treshna com>]

> I agree; thanks for the pointer, I just added them as enhancement
> requests for Conglomerate to Bugzilla:
> http://bugzilla.gnome.org/show_bug.cgi?id=136472
> (Papyrus)
>
> http://bugzilla.gnome.org/show_bug.cgi?id=136475
> (Rlib)
>
>
> Unfortunately the Papyrus XML format seems to lack both a namespace and
> a DTD, which makes it trickier to support within Conglomerate (it has to
> try and guess what XML doctype it's looking at).  But it's still
> possible.

should have public dtd now. (see bug report)


> > > Report Designer.
> > >
> > > None of have anything here (expect gnue).  Its needed. I was thinking
> > > orginally using openoffice or abiword to design reports but i really
> > > havn't started looking at this at any detail. Any suggestions on how we
> > > are going to achive this? Does this sound feasible?
> >
> > Either AbiWord or Conglomerate. I think Conglomerate is a good fit for
> > what papyrus is now. AbiWord would be quite a radical depature and the
> > document would be constructed "live" straight from the template. From
> > there we can export it to any one of your chosen file formats
> > (ps,pdf,latex,html) plus a whole lot more.
>
>
> I agree, looks like a good fit, though ideally I'd want to make some
> changes to the details of Papyrus' XML format.  It also doesn't seem to
> leverage XSLT; perhaps this could be used to add output->AbiWord and
> output->OO.org etc.

Any suggestions on what part of the xml format?
No it doesnt use xslt. Mostly because the xml to xml conversion part 
resolves data sources and does a bit of bison parsing which i dont know 
how a xml convertor could handle that. its not a big task to add a 
output->abiword or output->oo.org xslt covertor, but it would properly 
take a few days to code so i havn't worked on it before and been 
concentrating on other things.

> Within Conglomerate we could have support for editing Papyrus XML files,
> and a "Generate Report" option in the menus; these would be fairly easy
> to add using a plugin (maybe a 1 hour job for someone who knows our
> code?).
>
> I don't really care about what database abstraction layer is in use etc,
> I just want a sane XML format that describes how to generate the report,
> ideally some kind of standardised one supported by multiple projects.
>
> I'm not really a "database person", though so this stuff is low-priority
> for me, I'm afraid.  But I'll happily accept patches :-)