> >You'll have to create a GUI or use OS X. :-) Well, that leads me to the
> >question: What are you actually trying to do? We're talking about
> >solutions here, but not what you need them for (I think).
> >
> There's a very useful discussion going on about logging, Avalon, etc, 
> which covers this territory in more general terms.  Anything that 
> rationalises and makes consistent and readily understandable the 
> invovation and setup of FOP will be a very good thing.  I'm just talking 
> about the very limited aim of unifying and making more useful the 
> existing maintenance branch options/configuration code.

Right, I got that. And I appreciate your effort in this. My problem is
that I haven't yet seen the benefit of what you're trying to do. I
really think which we should have a least a third opinion on this.

> >>>I don't get you here. What do you need the language validation for?
> >>>
> >>For completeness.  I can specify country, language and script, and these 
> >>may be acted upon in respect of hyphenation.  Two situations may arise. 
> >> 1) That particular language/country/script may have no support in this 
> >>version of FOP.  2) There is no such language/country/script.  When I'm 
> >>parsing one of these attributes, I like to be able to detect the second 
> >>situation at the point of parsing.
> >>
> >
> >I'm lost. Sorry, but I really can't follow you.
> >
> My fault.  In the middle of this discussion about options processing, I 
> came across the references to the language file in the config file, so I 
> dragged them in, kicking and screaming.  "I can specify country.language 
> and script..." should read, "The user can specify country, language and 
> script..." as properties in the FO file that I'm processing.  See 7.9.2 
> "language", 7.9.1 "country", and 7.9.3 "script" in the Recommendation. 
> When I was looking at the parsing of such properties, I wanted to be 
> able to validate the element attributes immediately after they were 
> parsed by the expression parser.  I either had to hard-code the lists, 
> or provide for a way of updating them outside the code, so I went for a 
> configuration file, pointed to by the the general config file.

I see. Are those three not rather static so it would make sense to place
the resource files with the classes and hard-code the validation code.
That would make it simpler. Or do you see a case where you need to use a
different validation file? If you code something like this I'd
apreciate if validation could be switched of for performance reasons.

Jeremias Märki


Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to