[gnome-db] Re: GRAND MASTER PLAN

[Dru]

> 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 :-)