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.
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.
I do like Manuel's suggestion to supply a separate command line
validation option.
Note that we have not advertised the configuration schema. It is not
documented anywhere. I will add some documentation to the
configuration web page.
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.
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
