Tropo-Turing Collision: Voice Chat Bots with Tropo

On the first evening of PHPComCon this year, Tropo sponsored a beer-and-pizza-fueled hackathon. Having never heard of Tropo before, I decided to check it out.

Tropo provides a platform for bridging voice, SMS, IM and Twitter data to create interactive applications in Javascript, PHP, Python and a couple other languages. An example would be the call-center navigation menus with which many people are familiar, or a voicemail system that sends a text message when a new message is received. But those are only the tip of the iceberg.

To explore a little deeper, I thought it would be neat to create a voice chat-bot. The idea would be that a caller could talk to an automated voice in a natural way, and the voice would respond in a relevant way and push the conversation along. Since I wasn't aiming for Turing test worthiness, a good starting point was ELIZA, one of the first automated chat-bots. I thought it was a pretty ambitious project, but it turns out that Tropo's system handles all of the functionality right out of the gate.

The docs do a great job of explaining setting up an account and creating an application, so I'm going to jump right into the code (in PHP).

I like to keep my code relatively clean and organized, with functions and classes in their own files. So the first thing I did was create a hosted file called "Eliza.php" with the following contents:

class Eliza
{
  public function respondsTo($statement="")
  {
     $responses = array(
       "0" => "one",
       "1" => "two",
       "2" => "three",
       "3" => "four",
       "4" => "five",
       "5" => "six",
       "6" => "seven",
       "7" => "eight",
       "8" => "nine",
       "9" => "zero",
     );

     $response = "Please pick a number from 0 to 9";
     if (isset($responses[$statement])) {
       $response = $responses[$statement];
     }

     return $response;
  }

  public function hears($prompt)
  {
    $result = ask($prompt, array(
      "choices" => "[1 DIGIT]"
    ));
    $statement = strtolower($result->value);
    return $statement;
  }
}

It's important to note that the opening <?php and closing ?> should be left out of this file, or the next bit will fail.

The main functionality of the application is in the `Eliza` class. Eliza will translate a user input string into a response, which it will then use to prompt the user. The `ask()` function in the `hears()` method is functionality provided by Tropo's system that takes care of the text-to-speech and speech-to-text aspect of prompting the caller, and then waits for the caller to respond. The `choices => [1 DIGIT]` option to `ask()` hints that we expect the user to respond to our prompt with a single 0-9 character.

Next, I created a file called "chatbot.php" with the following contents:

<?php
$url = "http://hosting.tropo.com/00001/www/Eliza.php";
$ElizaFile = file_get_contents($url);
eval($ElizaFile);

$eliza = new Eliza();
$statement = "";
do {
  $prompt = $eliza->respondsTo($statement);
  $statement = $eliza->hears($prompt);
  _log("They said ".$statement);
} while (true);
?>

This is the entry script for the application, which can be set on the "Application Settings" page. Unfortunately, it does not look like Tropo supports `require` and `include` in their system. Fortunately, what they do provide are URLs to download the contents of any hosted file via simple `file_get_contents`. So we "inlcude" our Eliza.php file by downloading its contents, then `eval`ing them into the running scripts scope. Note: Yes I could have just written the contents of Eliza.php into the chatbot.php file, but a) it was more fun to try and find a way around that limitation :-) and b) many developers separate their code this way to keep it clean, encapsulated and reusable and this demonstrates a way to accomplish that.

The code is fairly self-explanatory: "include" and instantiate Eliza, then enter a prompt-respond loop which will last until the caller hangs up. `_log()` outputs to Tropo's built in application debugger.

I have to say congratulations to Tropo for creating a platform that makes all this easy. I had this up and running (except the file include portion) in about 15 minutes. You can try this out for yourself by calling (919) 500-7747.

So now that prompt-response was working, I could get started on making a real Eliza chat-bot that would parse the caller's speech and provide an Eliza-like response:

Caller: I'm building a voice chat application.
Eliza: Tell me more about voice chat application.
Caller: You're it!
Eliza: How do you feel about that?
Caller: I think it's pretty neat.

There are probably a hundred Eliza implementations on the web, and at least a dozen are written in PHP. I grabbed the first one I found, shoved it into the `Eliza::respondsTo()` method, and called up my application.

And this is where I hit the iceberg. In order to accomplish what I wanted, I needed the `ask()` function to be able to accept and parse any spoken words into a string. This meant getting rid of the `choices => [1 DIGIT]` line. As soon as I called, Eliza started prompting me over and over for input, until Tropo's system killed the loop and hung up.

Luckily, a Tropo guy (who was great to talk to, but who's name I have unfortunately forgotten) informed me that `ask()` works by using the `choices` option as training for the speech-to-text parser. There is a way to do generalized speech-to-text but it is incredibly processor intensive, and would have to make use of an asynchronous call. Later that evening, @akalsey confirmed that the current state of the technology (everyone's, not just Tropo's) makes generalized real-time speech-to-text processing impossible. So the dream of speaking with Eliza instead of just IMing with her dies unfulfilled, or is at least put on the shelf until technology catches up with ideas.

I did learn some about Tropo's service, though, so I count the hackathon successful. Thanks again, Tropo, for the great new tool!

Syntactic sugar for Vows.js

We end up writing quite a few full-stack integration tests. As the workflows for our projects get longer and more complex, the corresponding Zombie and Vows tests also get longer and more complex. Soon enough, a single test can be nested 15 or 20 levels deep, with a mix of anonymous functions and commonly-used macros.

Needless to say, these tests can become monsters to try and read through and understand:

var vows = require('vows');

vows.describe("Floozle Workflow").addBatch({
    "Go to login page" : {
        topic : function () {
            zombie.visit("http://widgetfactory.com", this.callback);
        },
        "then login" : {
            topic : function (browser) {
                browser
                  .fill("#username", "testuser")
                  .fill("#password", "testpass")
                  .pressButton("Login", this.callback);
            },
            "then navigate to Floozle listing" : {
                topic : function (browser) {
                    browser.click("Floozles", this.callback);
                },
                "should be on the Floozle listing" : function (browser) {
                    assert.include(browser.text("h3"), "Floozles");
                },
                "should have a 'Create Floozle' link" : function (browser) {
                    assert.include(browser.text("Create Floozle"));
                },
                "then click 'Create Floozle'" : {
                    topic : function (browser) {
                        browser.click("Create Floozle");
                    },
                    "then fill out Floozle form" : {
                        topic : function (browser) {
                            browser
                              .fill("#name", "Klaxometer")
                              .fill("#whizzbangs", "27")
                              .choose("#rate", "klaxes per cubic freep")
                              .pressButton("Save", this.callback);
                        },
                        // .... Continue on from there, with more steps
                    }
                }
            }
        }
    }
}).export(module);

So we created prenup, a syntactic sugar library for easily creating Vows tests. Prenup provides a fluent interface for generating easy to read test structures as well as the ability to reuse and chain testing contexts.

Here is the above test written with prenup:

var vows = require('vows'),
    prenup = require('prenup');

var floozleWorkflow = prenup.createContext(function () {
    zombie.visit("http://widgetfactory.com", this.callback);
})
.sub("then login", function (browser) {
    browser
      .fill("#username", "testuser")
      .fill("#password", "testpass")
      .pressButton("Login", this.callback);
})
.sub("then navigate to Floozle listing", function (browser) {
    browser.click("Floozles", this.callback);
})
.vow("should be on the Floozle listing", function (browser) {
    assert.include(browser.text("h3"), "Floozles");
})
.vow("should have a 'Create Floozle' link", function (browser) {
    assert.include(browser.text("Create Floozle"));
})
.sub("then click 'Create Floozle'", function (browser) {
    browser.click("Create Floozle");
})
.sub("then fill out Floozle form", function (browser) {
    browser
      .fill("#name", "Klaxometer")
      .fill("#whizzbangs", "27")
      .choose("#rate", "klaxes per cubic freep")
      .pressButton("Save", this.callback);
})
.root();

vows.describe("Floozle Workflow").addBatch({
    "Go to login page" : floozleWorkflow.seal()
}).export(module);

Every `sub()` call generates a new sub-context, and every `vows()` call attaches a vow assertion to the most recent context. `parent()` can be called to pop back up the chain and attach parallel contexts. If a context is saved, it can be reused in other chains. When `seal()` is called, it will generate the same structure as the original test.

More examples, including branching and reusing contexts, are given in the documentation. Prenup is available on NPM via `npm install prenup`

Dynamic Assets: Part III - Entry Forms

Now that we have instantiated our dynamically defined objects, we can get to the meat of our project: displaying a form based on the dynamic object.

My team uses Zend to build our forms, but the technique can easily be adapted for other frameworks. Since Zend_Form affords adding fields one at a time, we can easily build a form by looping through an Asset's field list:

$asset = $assetFactory->build('some_type');

$form = new Zend_Form();
// ... Set up our form action, method, etc. ...

$typeField = new Zend_Form_Element_Hidden('__asset_type');
$typeField->setValue($asset->getType())
    ->setRequired(true);
$form->addElement($typeField);

foreach ($asset->listFields() as $fieldName => $field) {
    if (!$field->isSubAsset()) {
        $fieldElement = new AssetFieldFormElement($field, $asset->$fieldName);
        $form->addElement($fieldElement);
    }
}

// ... Add a submit button, other form housekeeping ...

There are two interesting bits to the above snippet. Firstly, we intentionally skip rendering sub-asset fields as part of the form. We found it was easier to make the user create a parent asset before allowing them to assign sub-assets to it. This simplifies the form generation, display, validation and data persistence.

The second interesting bit is the introduction of a new class: AssetFieldFormElement. We give this class the field object for which to build form element(s), and the value of the field.

This class is where the heavy-lifting is done. The basic idea is to read the field information, instantiate a proper Zend_Form_Element object (or set of objects) and set the properties of that element. The rest of the class is mainly methods to pass through calls to things like "addValidator()", "render()", etc.

Using this class, we can turn any given AssetField object into a wide variety of HTML form elements. The simplest is a basic text box:

$field = new AssetField();
$field->setName("first_name");
$element = new AssetFieldFormElement($field, "Zaphod");

Rendered HTML:

<label>First Name</label> <input name="first_name" type="text" value="Zaphod" />

First Name 

If the field has a list of options, it renders as a drop-down. For things like the "date" type, we have a form element which will automatically attach a date-picker to the text box.

In a lot of cases, a single field will render as multiple form elements. For instance, sometimes a field's value can be an array of strings:

$field = new AssetField();
$field->setName("favorite_restaurants")
    ->setCollection(true);
$element = new AssetFieldFormElement($field, array("Milliways", "Stavro Mueller Beta"));

Rendered HTML:

<label>Favorite Restaurants</label>
<input name="favorite_restaurants[]" type="text" value="Milliways" />
<input name="favorite_restaurants[]" type="text" value="Stavro Mueller Beta" />
<input name="favorite_restaurants[]" type="text" value="" /><a href="#" class="adder" rel="favorite_restaurants">[+]</a>

Favorite Restaurants


[+]

A bit of Javascript on the "[+]" link allows the user to add more text boxes as needed (we can use the AssetField's "max" property to limit that if need be.)

Hang on, what if we we have a list of options for the user to choose from, but they can only choose each option once, and they need to be able to add their own if necessary? Not a problem:

$field = new AssetField();
$field->setName("drinks")
    ->setCollection(true)
    ->setUnique(true)
    ->setOptions(array("jynnan tonnyx", "jinond-o-nicks", "Ouisghian Zodah"))
    ->setOther("Something else?");
$element = new AssetFieldFormElement($field, array("jinond-o-nicks", "Pan Galactic Gargleblaster"));

Rendered HTML:

<label>Drinks</label>
<input name="drinks[]" type="checkbox" value="jynnan tonnyx" /> jynnan tonnyx
<input name="drinks[]" type="checkbox" value="jinond-o-nicks" checked="true" /> jinond-o-nicks
<input name="drinks[]" type="checkbox" value="Ouisghian Zodah" /> Ouisghian Zodah
<label>Something else?</label> <input name="drinks[]" type="text" value="Pan Galactic Gargleblaster" />

Drinks
 jynnan tonnyx
 jinond-o-nicks
 Ouisghian Zodah
Something else? 

A wide variety of form effects can be achieved through combining different asset field flags.

The other function that AssetFieldFormElement performs is adding appropriate validators to each form element. This allows us to use `$form->isValid($params)` just as we do with our application's static forms.

This is the last of the posts on dynamic class definition. I hope it was helpful.

Dynamic Assets: Part II - Construction

In the last post I introduced a feature in my team's current project that will allow our users (and us!) to dynamically define "assets", and I explained the syntax for defining an asset.

Now that we have our definition, we need to actually construct an asset instance. There are several classes involved here: the AssetField, which stores the display and validation information contained in the definition for a single field; the Asset which is basically a container wrapped around a list of fields and field values; and the AssetFactory, which reads a definition and constructs an Asset by hanging fields on it.

In the code below, I'm intentionally leaving out most of the gory details because they're boring and I'm focusing more on the design than the implementation.

AssetField is essentially a code translation of the JSON definition. Here's some of what it looks like:

class AssetField
{
    const TypeString   = 'string';
    const TypeInteger  = 'int';
    // etc. for each type
    
    protected $name = null;
    protected $display = null;
    protected $type = self::TypeString;
    // etc. for each attribute that can exist in a field definition
    
    public function getName()
    {
        return $this->name;
    }
    
    // All setters return $this to provide a fluent interface
    public function setName($name)
    {
        $this->name = $name;
        return $this;
    }

    // ... other getters and setters for each property
    // listed in the definition attributes ...
}

// Create a field named "power_sources" whose value is a unique array
// of one or more of the values "Gas", "Electric", "Solar"
// which defaults to having Gas and Solar turned on
// and allows the user to enter their own value if they need to.
$powerSourceField = new AssetField();
$powerSourceField->setName("power_sources")
    ->setUnique(true)
    ->setCollection(true)
    ->setOptions(array("Gas", "Electric", "Solar"))
    ->setDefault(array("Gas", "Solar"));
    ->setOther(true);

Every Asset object will carry around its AssetField objects, so that it can provide information about how it is built. This allows our form construction and validation code to be very generic.

Since Assets don't know what fields will be hung on them, we use PHP's magic `__get` and `__set` methods to set and return field values. However, during implementation we realized that the times we want to know the value of a field are very rare; more often, we want to know the properties of a field. So we also utilize the magic `__call` to give our code access to the underlying field object.

Here is what most of the Asset class looks like:

class Asset
{
    protected $type = null;
    protected $display = null;

    protected $fields = array();
    protected $values = array();

    // Return the field object when its name is called as a class method
    public function __call($fieldName, $args)
    {
        return isset($this->fields[$fieldName]) ? $this->fields[$fieldName] : null;
    }

    // Get the value of the named field
    public function __get($fieldName)
    {
        return isset($this->fields[$fieldName]) ? $this->values[$fieldName] : null;
    }

    // Set the value of the named field
    public function __set($fieldName, $value)
    {
        if (isset($this->fields[$fieldName])) {
           $this->values[$fieldName] = value;
        }
    }

    // Hang a new field on this asset
    public function addField(AssetField $field)
    {
        $name = $field->getName();
        $this->fields[$name] = $field;
        $this->values[$name] = $field->getDefault();
        return $this;
    }

    // ... Helper methods for returning the list of all fields
    // setting the Asset type, display string and instance name format ...
}

// Get an instantiation of our plumbing system example
$plumbing = new Asset();
$plumbing->setType("plumbing")
    ->setDisplay("Home Plumbing")
    ->setInstanceNameFormat("Installed %installation_date%");

$waterSource = new AssetField();
$waterSource->setName("water_source")
    ->setOptions(array("city", "well"))
    ->setOther("Where does the water come from")
    ->setDefault("city");

$installationDate = new AssetField();
$installationDate->setName("installation_date")
    ->setType(AssetField::TypeDate)
    ->setRequired(true);

$waterHeater = new AssetField();
$waterHeater->setName("water_heater")
    ->setType(AssetField::TypeSub)
    ->setOptions(array("gas_heater", "electric_heater"));

$showers = new AssetField();
$showers->setName("showers")
    ->setType(AssetField::TypeSub)
    ->setOptions(array("shower"))
    ->setCollection(true)
    ->setMax(5)
    ->setDefault(array());

$plumbing->addField($waterSource)
    ->addField($installationDate)
    ->addField($waterHeater)
    ->addField($showers);

// Use the asset 
$plumbing->water_source = "well";
$plumbing->installation_date = "06/05/2004";

echo $plumbing->getDisplay() . ": $plumbing";
// "Home Plumbing: Installed 06/05/2004"  <--- comes from an overloaded __toString method

echo "My water comes from a {$plumbing->water_source}"
// "My water comes from a well"

// Instantiate a new shower asset
$shower = new Asset();
// ... set up the asset ...

// add the shower to the plumbing system
$plumbing->showers[] = $shower;

// What is the default value for the water source?
$field = $plumbing->water_source();
$default = $field->getDefault();

Calling a field as a method will return the AssetField object for that property. The field object can then be used in forms and validation. Another benefit of dynamically constructing our Assets in this way is that we can customize any asset on the fly without affecting any other asset of that type. From our plumbing example, let's suppose one user wants to track the serial number of their water heater, but no one else does. We just make sure that any instantiation of a water_heater asset for that user gets an additional "serial_number" field:

// Continuing from above
if ($userId == $customAssetUserId) {
    $serialNumber = new AssetField();
    $serialNumber->setName("serial_number");
    $plumbing->addField($serialNumber);
}

Any form generation and validation code will automatically pick that field up and display it for that user.

The last important class for constructing Assets is the AssetFactory. All Asset instances are constructed through this factory. It takes a type definition, which in the plumbing example is a JSON string. The factory doesn't actually care where the definitions come from or how they are stored, as long as if receives a properly formatted array. AssetFactory is given definitions and then uses the definitions to construct Assets on demand:

class AssetFactory
{
    // List of asset recipes this factory knows how to bake
    protected $definitions = array();

    public function define($definition)
    {
        // ... Validate proper formed-ness of the definition ...
        // ... Set some reasonable defaults for non-specified field attributes ...

        // All assets get an id field
        $definition['fields']['id'] = array(
            'type' => DW_Asset_Field::TypeString,
            'hidden' => true,
        );

        $this->definitions[$definition['type']] = $definition;
    }

    // Construct an asset of the given type
    public function build($type)
    {
        $definition = $this->definitions[$type];

        $asset = new Asset();
        $asset->setType($definition['type'])
            ->setDisplay($definition['display'])
            ->setInstanceNameFormat($format);

        foreach ($definition['fields'] as $name => $fieldDef) {
            $field = new AssetField();
            $field->setName($name)
                ->setType($fieldDef['type'])
                ->setDisplay($fieldDef['display'])
                ->setHidden($fieldDef['hidden'])
                ->setUnique($fieldDef['unique'])
                ->setRequired($fieldDef['required'])
                ->setMin($fieldDef['min'])
                ->setMax($fieldDef['max'])
                ->setOptions($fieldDef['options'])
                ->setOther($fieldDef['other'])
                ->setDefault($fieldDef['default']);

            $asset->addField($field);
            $asset->$name = $fieldDef['default'];
        }

        return $asset;
    }
}

$factory = new AssetFactory();
$factory->define(json_decode('{
    "type" : "plumbing",
    "display" : "Home Plumbing",
    "instance_name" : "Installed %installation_date%",
    "fields" : {
      "water_source" : {
        "type" : "string",
        "options" : ["city", "well"],
        "other" : "Where does the water come from",
        "default" : "city"
      },
      "installation_date" : {
        "type" : "date",
        "required" : true
      },
      "water_heater" : {
        "type" : "subasset",
        "options" : ["gas_heater", "electric_heater"],
      },
      "showers" : {
        "type" : "subasset",
        "options" : ["shower"],
        "collection" : true,
        "max" : 5
      }
    }
  }'));

$plumbing = $factory->build("plumbing");

If we have any customizations, like our serial_number from above, we can call a `customize()` method on the factory from within the `build()` method, or pass the result of the `build()` to some other customization class. At the moment, we don't have any requirements like that. The important thing is that we now have an Asset object that we can pass around to our generic Asset handling code.

Next up, a description of how we generate a form from a generic Asset object.

Dynamic Assets: Part I - Definition

I am currently working on a feature of a project that allows users to track assets that exist at a location. The interesting part of the feature is that an asset can be almost anything, and that the properties of a single instance of an asset may have little or no overlap with the properties of a different asset.

Properties in this context refer not just to the attributes of an asset, but also to how those attributes are displayed, entered by the user when adding/editing an asset, and validated when the user is saving an asset. Assets can have sub-assets, forming a tree. And the most interesting wrinkle: users should be able to define their own assets, with properties' data-types, display and validation all user-controlled.

I'm not going to talk about how the assets are stored (until a few days ago it was a toss-up between schema-less MySQL or MongoDB.) Instead, what follows is series of posts describing our solution for defining an asset, displaying the add and edit forms and validating an asset. This first post covers how asset types are defined.

An asset is basically a bag of properties, and each property has attributes that define what values it can hold and hints about how it should be presented to the user when displaying or editing.

For example: the plumbing system in your home may have properties like "installation date" or "water source" (where water source may be either "city" or "well".) The system may also have sub-assets, like "water heater", which has properties like "type" (gas, electric, solar) and "last maintenance date". There might also be a list of "showers", which are also sub-assets, and have properties like "location", "size" and "needs to be cleaned".

Our first pass was to define a class for each asset type, which would include the type's properties and how those properties should be displayed. The problem with this solution was two-fold: first, we don't currently know what properties each of our assets will or won't need to have (so an asset type's schema will be in flux); and second, we don't want our users to have to write code in order to define their own asset types. In fact, we don't know all the assets we will need to track for our own purposes yet.

Our solution was to store asset definitions as data instead of code. Then, all we need is a mechanism that reads a definition and builds a dynamic "class-less" asset object. The definition syntax is JSON, though the code that actually constructs concrete Asset instances doesn't care how the definitions are stored.

Here is some of the definition for the above plumbing system (I've intentionally added some constraints to demonstrate other bits of the definition syntax):

{
  "plumbing" : {
    "type" : "plumbing",
    "display" : "Home Plumbing",
    "instance_name" : "Installed %installation_date%",
    "fields" : {
      "water_source" : {
        "type" : "string",
        "options" : ["city", "well"],
        "other" : "Where does the water come from",
        "default" : "city"
      },
      "installation_date" : {
        "type" : "date",
        "required" : true
      },
      "water_heater" : {
        "type" : "subasset",
        "options" : ["gas_heater", "electric_heater"],
      },
      "showers" : {
        "type" : "subasset",
        "options" : ["shower"],
        "collection" : true,
        "max" : 5
      }
    }
  },

  "another_type" : {
    ...
  },
  ...
}

All assets must have a "type", which must be unique among all asset definitions. "display" is an optional field; if not specified, the display is the "type" string upper camel-cased and with underscores replaced with spaces (e. g. "plumbing_system" becomes "Plumbing System"). The display is used to identify an asset instance's type to the user, mainly on entry/edit forms and reporting.

The "instance_name" is the formatting string used to present a specific asset to the user. Wrapping a field name in %'s will substitute the actual value of that field when displaying the asset to the user. In the above example, if a plumbing asset has an installation date of "6/12/2009", then the asset would be displayed to the user as "Installed 6/12/2009". If no instance_name is given, the instance name defaults to the asset's id.

The rest of the asset is a list of fields, indexed by the internal field name, and each having some combination of descriptive attributes. The "type" attribute is the only required attribute for a field, and must have one of the values "string", "int", "boolean", "datetime", "date", "float" or "subasset". The difference between date and datetime is purely in the way that they are presented to the user (and how granularly the value is stored: dates are always rounded to midnight.)

"required" is a boolean flag indicating whether the asset can be saved without a value in that field or not. "hidden" is another boolean flag, specifying if the field should be presented to the user. We have to be careful that if a field is required and hidden the application must provide a value. A good way to do that is with the "default" attribute, which specifies the default value for that field. If the field is not hidden, the default value will be pre-entered or selected for the user on an "Add Asset" form.

The "options" attribute lists the valid values for a field. The exception is for "subasset" fields, in which case options is a list of valid subasset types (in our plumbing example, gas heaters and electric heaters could be their own asset types with their own set of fields, and an instance of either would be a valid value for the "water_heater" field.) If no type options are listed for a subasset field, any asset type is assumed to be valid.

If a user should be allowed to enter their own value in addition to the, then the "other" attribute can be used. If "other" is a boolean true, then an "Other" option will be added to the list of options, and the user will be able to enter whatever value they like. "other" can also be a string, in which case it is the text to display as the "Other" option, and the label on whatever form field is used to capture the user's input.

Some fields hold multiple values. In these cases, the "collection" attribute is set to boolean true. By default, the same value can appear in the collection multiple times. If that is not desired, the "unique" attribute can be used to validate that each value appears only once. Using combinations of "collection", "unique" and "options" can drive some pretty complex form behaviors (which will be shown in a future post.)

There are also "max" and "min" attributes. On a collection, the value of the attributes are integers specifying how many values are allowed to be in that collection. Otherwise, they represent upper and lower bounds on integer, float, date and datetime values.

The definition syntax so far gives us all the flexibility we need to define our project's known asset types, and we believe it will be useful in the future for easily adding new types and allowing our users to define their own assets types (probably through a form that translates into the JSON definition.)

Part II will be an overview of we actually use these definitions to form "class-less" asset objects on-the-fly.