Ok, but with your statement you're carefully avoiding the topic about how to actually validate the configuration. Are we then writing a number of plug-ins which contain manually written code that verifies the config file on the various levels (root, renderer, fonts....)? Possible, not difficult but takes quite a bit of work to get done.
On 10.09.2006 16:03:06 Manuel Mall wrote: > On Sunday 10 September 2006 20:52, Jeremias Maerki wrote: > > Ok, I consider myself defeated concerning the way we handle the > > configuration file (See recent threads on fop-users). The Avalon > > configuration approach is very nice for the developer but obviously > > bullshit in terms of end-user-friendlyness. The attempt to overlay > > the configuration layout with an XSD is generally a good idea but > > with the current configuration layout, it's not a workable solution. > > > Not sure I agree with the "bleak" picture you are painting. In my > assessment most problems seem to be caused by the change of config > format from 0.20.5 to 0.9x. Not by the format itself. > > What about having a command line option which triggers a config file > validation. Similar to Apache HTTPD: > apachectl -t > > "Run a configuration file syntax test. It parses the configura- > tion files and either reports Syntax Ok or detailed information > about the particular syntax error." > > Manuel > > If anyone has a good plan to improve the situation, I'm all ears. I > > think the configuration file needs to be built based on an XML Schema > > and FOP should by default validate the configuration file (hard-coded > > in FOP) so the users get proper feedback if they try to feed FOP with > > an invalid format. But that means the XML Schema must be water-tight. > > On the other side, we will probably lose extensibility of the > > configuration file format. When someone adds his own renderer, for > > example, he can't just have his own config values because he can't > > change the XML Schema. So that may mean we probably can't use XML > > Schema to validate the file. But then, maybe we can define the > > individual renderer config parts as xsd:any or something like that > > and let each renderer validate its own configuration (either manually > > or using an XSD). > > > > ATM, I can't think of a good solution but apparently, we need to > > change something at some point. Any ideas, thoughts? > > > > Jeremias Maerki Jeremias Maerki
