I wouldn't go that far. A proper schema validation already tells you if
you have an element in the wrong place. Besides that I guess what I want
most is that users read and interpret error messages. :-)

On 13.09.2006 20:31:03 Simon Pepping wrote:
> On Tue, Sep 12, 2006 at 09:37:20PM +0200, Jeremias Maerki wrote:
> > 
> > On 12.09.2006 21:13:35 Simon Pepping wrote:
> > > 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.
> 
> This sounds like you want to catch user errors in any case. That would
> be a custom program that applies heuristics based on knowledge of
> common user errors. For example,
> 
> 'Do you mean to configure font XXX? I found a font configuration
> element in a position where FOP will not pick it up.'
> 
> Class UserConfigDoctor.
> 
> A possibility besides Java is to do it in XSLT, in the manner of
> Schematron. Write templates for known suspect XPaths in the file, such
> as all font elements not in /*/renderers/renderer/fonts.
> 
> Regards, Simon
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.eu



Jeremias Maerki

Reply via email to