Re: data types and inheritance

[Bruno Haible <bruno clisp org>]

Roozbeh Pournader wrote:
> I see only one problem: what should happen for user configuration?
>
> I used to assume that a user configuration file should be something that
> gets added at the end of the "locale chain" as the inheritance is
> concerned. So, it would work as if the user is running under the the
> locale "fa_IR_CUSTOM". This may require the whole XML set when one (say,
> a web application) encounters some small code (which may contain
> aliases, etc) passed to it from the client application.
> ...
> But I guess the cooker should also be able to create an expanded XML
> file (with all inheritance, alises, and default attribute values
> expanded), something that would result essentially in the same cooked
> file but without reading any extra file, in case the user wants to pass
> her whole settings around to someone else, like a web application.

So far, I've been imagining that the cooker works as follows. Let's see
whether this is enough for user configuration.

- The runtime library looks for its mmapable files at one single place
  in the filesystem. This location can be set through an environment
  variable ("GLOCDIR"), allowing use cases such as
    1) A locally modified set of mmapable files under $HOME/.glocale,
    2) "make check" inside the library itself.

- The cooker has an in-memory representation of the locale data, plus
  the following converters:

     glibc          --> in-memory
     LDML XML       --> in-memory
                        in-memory --> mmapable files
     mmapable files --> in-memory

  It also needs a "merge" operation that takes two in-memory representations
  and merges them, giving preference to one or the other. This is certainly
  needed to create the combination of glibc data and CLDR data, with
  preference for one or the other.

The questions that you've raised are:

1) Why only a single lookup location, and not several ones ("GLOCPATH")?
   The answer is: The cooker can do it. It is acceptable if the cooker
   regenerates the whole set of mmapable files, not just part of it.
   [OK, _if_ the cooking pass turns out to be too slow at the end, we can
   introduce GLOCPATH instead of GLOCDIR. It's a modification in two or
   three files.]

2) How to create an expanded XML?
   Simple: Write an  in-memory --> XML converter.  It's work, sure.

3) How to create a minimal differential XML?
   Like the "merge" phase: takes two in-memory representations as input,
   and produces a single one as output, possibly with many missing fields.
   Then the in-memory --> XML converter is applied.

How does this fit you?

Bruno