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
