<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I think I'm missing a little context here... if you have some xml like<div><foo a="1" b="true" c="1/18/09/"></div><div>how does a type declaration explain that b is a boolean and c is a date? </div><div><br></div><div>Sarah</div><div><br><div><div>On Feb 9, 2009, at 12:41 PM, P T Withington wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>We've had some internal discussions on this. This summarizes my thoughts. Input from the community would be welcome.</div><div><br></div><div>We have 3 type systems in LZX: 1) XML types, 2) Javascript types, 3) presentation types. XML types are defined by XML, but we have extended them. The XML types define how the tag-compiler parses/evaluates/defaults attribute values into the Javascript types used by the runtime. They all have a corresponding Javascript type, which is how the value is represented in Javascript, and we have recently added (internally to the LFC) the concept of a "presentation type", that defines how an XML/Javascript type is mapped to/from a string representation in a dataset.</div><div><br></div><div>I think we can reduce the complexity of this system by integrating XML types and presentation types, making presentation types the mechanism whereby one can define new XML types in LZX. Presentation types can codify the algorithms for the tag-compiler to parse attribute values into their Javascript representation.</div><div><br></div><div>We would like to extend presentation types in two ways:</div><div><br></div><div>1) To become the mechanism for defining new LZX types. For instance, for the built-in type boolean:</div><div><br></div><div><type name="boolean" jstype="Boolean"></div><div> <method name="accept" arg="string"></div><div><div> switch (string.toLowerCase()) {</div><div> case "": case "0": case "false":</div><div> return false;</div><div> default:</div><div> return true;</div><div> }</div><div> </method></div></div><div> <method name="present" arg="value"></div><div> return (!! value)? "true" : "false";</div><div> </method></div><div></type></div><div><br></div><div>Or adding a new type date:</div><div><br></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; "><type name="date" jstype="Date"><br> <method name="accept" arg="string"><br> return new Date(Date.parse(string));<br> </method><br> <method name="present" arg="date"><br> return date.toString();<br> </method><br></type><br><br>This defines the LZX type `date` which is represented in JS as a `Date` object.<br></span></div><div><br></div><div>2) to map XML/Javascript types to/from components (simple example: map to a text-edit component and use the existing string mapping; more complex: define protocols for presentation-type to component mapping based on type theory, range, dimension, enumerability, etc.) </div><div><br></div><div>At a minimum, we would add `validate` and `describe` methods for types, which the component can use to test if an input value is permitted and to create a tooltip or other help to assist the user in entering a correct value. E.g., we might add to the `date` type:</div><div><br></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; "> <method name="validate" arg="string"><br> return (! isNaN(Date.parse(string)));<br> </method<br> <method name="describe"><br> "A date in UTC format"<br> </method><br><br></span></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; ">There will have to be more methods to interface with more complex components.</span></div><div><font class="Apple-style-span" face="-webkit-monospace"><br></font></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; ">---</span></div><div><font class="Apple-style-span" face="-webkit-monospace"><br></font></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; ">As an added benefit, we could use this same mechanism to codify the debugger's interface and allow users to define how the debugger represents types, describes and inspects objects, without having to add methods to the actual type.<br><br><br></span></div><div><br></div><div><br></div> </div></blockquote></div><br></div></body></html>