On 12.09.2006 21:13:35 Simon Pepping wrote: > Jeremias, > > What is the problem you are trying to address: > > 1. Users use configuration files with errors which can be detected by > the fop-configuration schema, but they do not validate it. > > 2. Users use configuration files with errors which cannot be detected > by the fop-configuration schema.
Both as well as a few others. :-) > Ad 1: It is perfectly possible to let fop validate the user > configuration file in a command line invocation. The problem is to > ensure that the location of the schema does not become a source of > errors in its turn. It is possible to write an Entity and URI Resolver > which looks for 'fop-configuration.xsd' along the classpath, and for > other schemas and DTDs delegates to a CatalogResolver if that is > available, and otherwise returns the absolute URI of the system or > schema location path. > > Re extensibility: A XML file is validated according to the DTD or > schema that it declares (Relax-NG is an exception). The user can put a > DTD or schema of his own choice in the user configuration file: > > <!DOCTYPE fop > PUBLIC '-//MYSELF//DTD My FOP Configuration XML V1.0//EN' > 'http://myserver.mydomain.eu/fop-configuration.dtd'> > > and the parser will validate against it. This means that a user can > extend the configuration file at will, and that FOP cannot be assured > that the config file is valid. Embedded users can always avoid > validation. Yes, but you already assume a non-novice user. If our goal is to have less problems, fewer support requests because of configuration errors, we have to do it fool-proof. You can't rely on everyone putting the DTD or XSD on top of the configuration file. The first time the XML doesn't validate, people remove the schema reference. > I do like Manuel's suggestion to supply a separate command line > validation option. Me, too. You'll still have to tell the people to use the switch after they've run into a problem. That's why I'm in favor of forcing configuration validation for the command-line (but not for embedded use). > Note that we have not advertised the configuration schema. It is not > documented anywhere. I will add some documentation to the > configuration web page. +1 although I don't think it solves any of the problems for the group of people I'm currently looking at. > Ad 2: The schema cannot enforce a specific content model depending on > the type attribute. But it does a nice job limiting the > possibilities: One cannot mix and match parts of different renderer > configuration options. For example, it is perfectly possible to > configure a PostScript renderer with the elements applicable for a PDF > renderer. But it is not possible to start with a filterList, and > continue with auto-rotate-landscape. > > It is possible to force the correct content model for each renderer > type by giving them different element names, > e.g. renderer-application-pdf or application-pdf for short. Exactly my point. We have to change at least the configuration layout to improve the situation. The current layout cannot be validated satisfyingly against an XSD. Sure, I overreacted again. I know that and I'm sorry. But the longer I'm on the fop-users list the more I think we have to build fool-proof software. OTOH, as long as people don't use their brains when reading the simplest of warning messages there's no hope anyway. > Regards, Simon > > On Sun, Sep 10, 2006 at 02:52:31PM +0200, 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. > > > > 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 > > > > -- > Simon Pepping > home page: http://www.leverkruid.eu Jeremias Maerki
