On Wed, Jul 23, 2008 at 03:54:09PM -0500, Shawn Walker wrote: > >> 2. Is it possible to create property groups of property groups (the > >> dtd suggests that this is not possible)? > > > > Correct. Not possible. > > Hrm, someone mentioned that: > > You can manage a pool of configuration values using the property group > mechanism, with an overall property group listing the relevant group > or groups for each member. > > What did they mean by that then?
You can have one pg/prop naming dynamically-created pgs that are part of an ad-hoc group-of-pgs. That'd be totally ad-hoc. But doable. > >> 4. I have a need for users to be able to specify values to the > >> program based on locale. This is not the locale that the program is > >> running in, but the locale of the content being generated by the > >> program. For example, I have a property group called "repository" and > >> a propval called "name". What is the best way for them to be able to > >> specify a value for "name" for each locale (e.g. en, fr, etc.)? > > > > We currently do this with a convention of appending the locale name to > > the property name. We don't have explicit formal support for it at this > > point, though. > > That format would require me to specify a propval for each supported > locale though would it not? Would it be better to use a multiple-value > property instead and have the user pre-pend the locale to each value > (e.g. en:value, fr:value)? You can have any convention you wish. Heck, you could use Unicode and the Unicode language codepoints. Unicode has codepoints whose purpose is to indicate that the following text is in some language, which is mostly only useful for this sort of thing, and for selecting different font styles (this is important for CJK), but usually apps know the language from context, thus these codepoints are mostly not used IIUC (nothing stops you from using them if you wish, except that you'd be committing to using Unicode). Presumably you'll support various codesets, so you're probably best off using SCF_TYPE_OPAQUE for all non-ASCII and non-UTF-8 character strings A codeset-aware string type for SMF would be nice where Unicode (UTF-8, specifically) and US-ASCII are not good enough. It would allow the UIs to perform codeset conversion so as to properly display such values. (Cue Roland :) But again, an ad-hoc solution is possible. Nico --
