From: Clark C . E. <cc...@cl...> - 2001-08-03 19:39:42
|
On Fri, Aug 03, 2001 at 02:02:15PM +0200, Oren Ben-Kiki wrote: | My proposal: use the %(<key><value> ...) shorthand for the color keys. The | '%' makes it clear there's a map involved (or, for a complete newbie, that | something fishy is going on). It is short, extendible, but not *too* | extendible. I think we are awfully close. Now that you mention it, I *do* like the idea of two information models: YAML-BASE: Untyped tree information model consisting of Map, List, Scalar, and Null. YAML-CORE: Typed graph information model building on the base model. I'm completely opposed to the %() thingy. If someone has a map, then they can use special __type__ keys to designate the type of the map, etc. One moves from the YAML-BASE to YAML-CORE with several regular expressions which act *only* on Scalar values. There are two categories of regular expressions: A. Those that recognize specific indicator keys. This category includes: 1. A mechanism which uses &0001 and *0001 per our first specifcation to build a graph. 2. A mechanism which uses !type to identify a particular class or data type. B. Those that recognize specific data types for simple one line, unquoted scalar values: 1. Integer detection (2345) 2. Float dection (2.34e0) 3. Rational dection (3.45 and 2 3/8) 4. Date/Time dection (2001-03-23, 23 MAR 2001) 5. Complex dection (3+8i) etc. An binding to YAML then specifies through a mask which regular expressions are in effect as determined by what is supported by the given language. Thus, if date/time is supported by the language, then the date/time dection is enabled; otherwise, a string is the returned value. To re-iterate however, I'm very much opposed to the idea of a "scalar" in the YAML document becoming a "map" in the information model. Bad idea. For those "special" attributes (such as type and reference to) it is better to have a layered information model. | - We review the information model - make it more formal and support only | map/list/string/null. Ok, but only under the recongition that this is the BASE information model, and not the CORE or normal information model. | - We unify Clark and Brian's proposals for auto-detection of a value, | including the top-level value. Ok. | - We put the %(...) shorthand format in the core spec, but without | describing the semantics of any special keys. I'd rather do something like the above. |