Here's an important question that needs answering, before we can really go anywhere with this:
If I define a new type, say `trilean`, that is stored as 0, 1, or 2, but is meant to represent a tri-state yes/no/maybe button in a form, when I write: <attribute name="again" type="trilean" value="???" /> What is the expectation about the `value` field? Currently, for all the built-in presentation types, (except for color), `value` is interpreted as the corresponding Javascript type, but maybe this is just luck because the Javascript type and the LZX type look similar enough no one noticed. E.g., I say: <attribute name="ok" type="boolean" value="false" /> I use the Javascript value `false`, not the representation `"false"` (which is how a boolean would be stored in a dataset). If we extend that model, for my trilean, I would have to write: <attribute name="again" type="trilean" value="2" /> which is not really helpful. I would have to remember wether `2` corresponds to "yes", "no", or "maybe". I would much rather write: <attribute name="again" type="trilean" value="maybe" /> Is this what people expect? I'm not sure how we could reconcile the current built-in types with this new distinction. It makes me think that we need a new property of attribute that is the "representation type"? <attribute name="again" type="trilean" ???="maybe" /> What's a good name for that? [that leaves open the issue of how I write Javascript code to manipulate `this.again` -- there I need to know the corresponding values. Probably I want to be able to say: if (this.again == lz.trilean.yes) ... or something.]
