The first attempt at getting the complete, internal data model to generate a proper text output resulted in the phrase “(space) (space) to the store.” That’s two leading spaces where there should have been text. That’s fine, it’s all part of the debugging part of software development, but getting there was quite the adventure.

The current internal data model looks like an old-timey telephone switch board. There’s cross-references all over the place to allow for generation of data while keeping it flexible for future changes. The primary organization is a tree structure, similar to a computer storage directory.

/module
    /0000-core
        /person
            /possessions
                /transportation: group attribute for group '/module/0000-core/transportation'
        /transportation: group definition, which contains:
                * 'foot': reference to '/module/0000-core/transportation/foot'
            /foot
                /v-travel: text localization lookup to '/module/0000-core/text:transportation/foot/v-travel'
    /0001-addon
        /player-name-list: localization lookup to '/module/0001-addon/text:player-name-list'
/world
    /+player
        /@name: value "0" for attribute '/module/0001-addon/player-name-list'
        /possessions/transportation: value 'foot' for attribute '/module/001-addon/player-name-list'

To start with, there’s different kinds of things that the internal model stores. Eventually, the system will allow for generating data based upon various restrictions. Those restrictions define attributes that have restrictions on what values can be used, and references to other values.

Group definitions are collections of words or phrases (“group item”), each with a specific reference. A group attribute indicates an attribute that can store 0 or more of those group items from one group definition. A group value is a specific thing’s collection of group items for that group attribute.

A text localization lookup is a reference to the localization dictionary, which as a domain and a message id. Localization lookups support several different modes of operation, but for this discussion we’ll limit it to a name list and a grammar string.

A name lookup requires an index into the name list. It’s just a number that references a position; if the number is bigger than the list, then it’s divided by the length of the list, and the remainder (if you remember long division) is the new position. That corresponding position is the name used in the text.

A grammar string is an extra bit of letters used to indicate in what way is the looked-up localized text used in the sentence. These characters only have meaning within the context of the language and locale being used, but can indicate whether a noun is the object or subject of the sentence, or whether a verb is past tense or passive voice, or any other grammatical information necessary to choose the right word.

In this situation, the localization lookup is:

  • /module/0000-core/text:transportation/foot/v-travel: “walked”
  • /module/0000-core/text:transportation/foot/v-travel:r: count = 1: “walks”, count > 1: “walk”
  • /module/0001-addon/text:player-name-list: [ “Chris”, “Sam”, Alex” ]

And I’m attempting to use the internal data structure above with that localization setup to process the text “{t:/world/+player/@name} {x:/world/+player/posessions/transportation;{t:/current/0/v-travel}} to the store.”